perm filename WORKS.MSG[UP,DOC]3 blob
sn#610128 filedate 1981-08-31 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00171 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00015 00002 Subject: Welcome to APOLLO
C00019 00003 Subject: Themes for discussion
C00022 00004 Subject: Preliminary results from the personal workstations survey
C00029 00005 Subject: personal computer economics
C00031 00006 Subject: Re: Another Xerox workstation.
C00033 00007 Subject: SAM/Worm/820
C00035 00008 Subject: personal computer economics
C00039 00009 Subject: personal computer economics
C00041 00010 Subject: Subjective value of Personal Workstations
C00044 00011 Subject: Star/Mesa
C00046 00012 Subject: Star
C00049 00013 [Subj: Mesa language, PDP10, etc]
C00051 00014 Subject: Re: Speaking up Xerox!
C00053 00015 Subject: Workstations, and their posts.
C00057 00016 Subject: correction on dlw's message
C00060 00017 Subject: Acquiring personal computers
C00065 00018 Subject: Arpanet usage
C00068 00019 Subject: Stars in the sky
C00072 00020 Subject: Productivity gains without using workstations
C00075 00021 Subject: Star Info
C00077 00022 Subject: Re: Apollo Network
C00083 00023 Subject: Quick overview/summary: The Apollo-I (Domain) computer.
C00086 00024 Subject: Re: Star Info
C00089 00025 Subject: Re: Star Info/Smalltalk
C00091 00026 Subject: Re: Smalltalk
C00093 00027 Subject: Chromatics
C00099 00028 Subject: Burroughs OFIS products
C00103 00029 Subject: Re: Works: Re RIvanciw: OA Architecture
C00107 00030 Subject: Apollo files and network
C00109 00031 Subject: Comment on note on Apollo Network
C00111 00032 Subject: Re: Quick overview/summary: The Apollo-I (Domain) computer.
C00113 00033 Subject: APOLLO net
C00116 00034 Subject: My CT system configuration and Chromatics
C00119 00035 Subject: Re: Personal Workstations -- who for?
C00125 00036 Subject: Interupting a workstation session
C00129 00037 Subject: Shades of Nicholas Negroponte
C00131 00038 Subject: Tools for personal workstations
C00134 00039 Subject: Languages for Distributed Workstations
C00140 00040 Subject: system architecture
C00143 00041 Subject: Mini/Micro Systems June 1981
C00144 00042 Subject: Re: Xerox Dolphin (alias 1100?)
C00150 00043 Subject: Personal Workstations
C00153 00044 Subject: The Economics of Workstations
C00160 00045 Subject: Interupting a workstation session
C00163 00046 Subject: Re: Tools for personal workstations
C00164 00047 Subject: frisbees and floppies...
C00166 00048 Subject: Addressing and File Accessing
C00169 00049 Subject: Re: el.POBox 19 Jun 81 7:36-EDT
C00170 00050 Subject: Multiple Levels Of State
C00174 00051 Subject: Re: Tools for personal workstations
C00178 00052 Subject: On productive text editors, suggested reading includes
C00179 00053 Subject: ALANTHUS System 1000 workstation
C00181 00054 Subject: Re: Xerox Dolphin (alias 1100?)
C00183 00055 Subject: Xerox 1100 (Dolphin)
C00185 00056 Subject: ALANTHUS System 1000 workstation
C00187 00057 Subject: Clarifications about interrupting workstaions
C00190 00058 Subject: Re: Multiple Levels Of State
C00192 00059 Subject: Question to field: Bit Mapped displays
C00193 00060 Subject: Addressing and File Accessing
C00195 00061 Subject: Re: File accessing?
C00196 00062 Subject: Re: Addressing and File Accessing
C00200 00063 Subject: Errata on Barns message "Addressing and File Accessing"
C00204 00064 Subject: Storage Question Restated
C00209 00065 Subject: Re: Addressing and File Accessing
C00212 00066 Subject: Re: Question to field: Bit Mapped displays
C00216 00067 Subject: capability machines
C00218 00068 Subject: Re: Addressing and File Accessing
C00222 00069 Subject: Re: Addressing and File Accessing
C00226 00070 Subject: Xerox 820 Ethernet compatability
C00228 00071 Subject: EMACS -vs- UNIX
C00235 00072 Subject: CMU Workstation milestone
C00236 00073 Subject: Re: Ethernet capabilities of 820 and STAR
C00244 00074 Subject: Switching tasks and context
C00248 00075 Subject: Multiple Levels of State
C00251 00076 Subject: Spatial design for a workstation
C00262 00077 Subject: Ivanciw's ideas &c: comments
C00267 00078 Subject: Re: Tools for personal workstations
C00269 00079 Subject: Re: capability machines
C00271 00080 Subject: Re: Spatial design for a workstation
C00273 00081 Subject: Contexts as Icons
C00277 00082 Subject: Multiple Levels of State
C00279 00083 Subject: Re: Switching tasks and context
C00283 00084 Subject: not putting phone messages into electronic mail files
C00285 00085 Subject: Re: A Quibble or two
C00289 00086 Subject: Re: not putting phone messages into electronic mail files
C00292 00087 Subject: Re: not putting phone messages into electronic mail files
C00295 00088 Subject: speaking of touch panels...
C00296 00089 Subject: Re: Spatial design for a workstation
C00298 00090 Subject: Context Managers
C00302 00091 Subject: Re: Re: Tools for personal workstations
C00303 00092 Subject: Re: Contexts as Icons
C00305 00093 Subject: Unfinished tasks, intra-office mail, and system death
C00309 00094 Subject: Re: A Quibble or two
C00311 00095 Subject: Reliability
C00315 00096 Subject: Re: JWalker comments on working at home, on planes, etc.
C00319 00097 Subject: Working at home
C00323 00098 Subject: Office of Tomorrow, where is it?
C00326 00099 [Subj: Bravo/Hypertext]
C00328 00100 Subject: Workstation Reliability and Redundancy
C00334 00101 Subject: Automated desk
C00337 00102 Subject: Re: Context Managers
C00338 00103 Subject: Icons
C00340 00104 Subject: Re: Reliability
C00344 00105 Subject: Touchpanels
C00348 00106 Subject: Re: Touchpanels
C00362 00107 Subject: Picture vs. Window names
C00369 00108 [Subj: more on icons]
C00371 00109 Subject: Re: Unfinished tasks, intra-office mail, and system death
C00373 00110 Subject: Reliablity
C00375 00111 Subject: SUN Workstation
C00377 00112 Subject: Collected Responses on Touchpanels II
C00392 00113 Subject: Re: Picture vs. Window names
C00394 00114 Subject: pukcba ekortsyek
C00396 00115 Subject: Making paper go away
C00401 00116 Subject: Programming by example
C00409 00117 Subject: Re: Reliablity
C00411 00118 Subject: PIE reports from PARC
C00412 00119 Subject: Quickie poll
C00413 00120 Subject: Re: Making paper go away
C00416 00121 Subject: Re: Making paper go away
C00420 00122 Subject: Making paper go away
C00424 00123 Subject: Re: Office of Tomorrow, where is it?
C00428 00124 Subject: Icons and analogy
C00432 00125 Subject: Redefining the art
C00434 00126 Subject: Re: Re: A Quibble or two
C00438 00127 Subject: Re: Spatial design for a workstation
C00445 00128 Subject: Re: Spatial design for a workstation
C00449 00129 Subject: Collected responses on terminal input devices
C00461 00130 Subject: Bell Labs "writers workbench"
C00462 00131 Subject: writing aids
C00463 00132 Subject: Realtime proofreaders
C00466 00133 Subject: Configuration
C00470 00134 Subject: [don: EP]
C00473 00135 Subject: Alternatives to making paper go away
C00476 00136 Subject: Re: Making paper go away
C00480 00137 Subject: Scanning structured text
C00482 00138 Subject: Editing
C00486 00139 Subject: Writing English
C00489 00140 Subject: Ideal word-processor
C00493 00141 ["Automate the Business Office--How and When"]
C00496 00142 Subject: Talking Workstations, that elusive 'external device'.
C00498 00143 Subject: mice,balls,touch-plates,pens.
C00501 00144 Subject: Re: Configuration
C00506 00145 Subject: Collected Responses on Terminal Input Devices
C00519 00146 Subject: terminals versus comp centers
C00522 00147 Subject: Collected responses on terminal input devices
C00543 00148 Subject: WorkS problems
C00547 00149 Subject: Realtime proofreaders
C00551 00150 Subject: File Backup
C00556 00151 Subject: Collected responses on terminal input devices
C00568 00152 Subject: More on configuration
C00574 00153 Subject: WorkS Software.
C00577 00154 Subject: Collected responses on useable systems
C00584 00155 Subject: Sperry Univac workstation design group -- eyewitness testimony
C00590 00156 Subject: Sperry Univac workstation design group -- eyewitness testimony
C00596 00157 ∂26-Jul-81 2028 AVB Xerox announcement on Dolphin/1100
C00604 00158 Subject: "mundane" systems
C00609 00159 Subject: re: REM' s remarks on Global configurations
C00614 00160 Subject: apollo s/w release 2.0
C00618 00161 Subject: Mouse Guts
C00624 00162 Subject: Big AND Small
C00632 00163 Subject: Keystroke Monitoring
C00635 00164 Subject: WorkS Digest V1 #1
C00646 00165 Subject: WorkS Digest V1 #3
C00657 00166 Subject: WorkS Digest V1 #4
C00660 00167 Subject: WorkS Digest V1 #5
C00678 00168 Subject: WorkS Digest V1 #6
C00687 00169 Subject: WorkS Digest V1 #7
C00694 00170 Subject: WorkS Digest V1 #8
C00701 00171 Subject: Announcements - ANSI Standards Comm. & NCC82 Call for Papers
C00707 ENDMK
C⊗;
Subject: Welcome to APOLLO
∂05-Jun-81 2215 DUFFEY at MIT-AI (Roger D. Duffey, II) Welcome to APOLLO
Date: 6 JUN 1981 0115-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: New APOLLO Subscribers
Hello,
Welcome to the APOLLO mailing list. APOLLO discusses personal
work station computers, like the APOLLO work station computer,
BBN's Jericho, the Three Rivers Corporation PERC, or the newly
announced Xerox STAR. APOLLO provides a way for interested
members of the ARPAnet community to discuss what is wrong with
these machines, compare notes on work in progress, and share
useful insights about these kinds of systems. The list is
managed by Hank Dreifus <Dreifus at WHARTON>.
APOLLO is currently discussing initial reactions to the Xerox
Star Workstation. Sandor Schoichet <SROSS at MIT-XX> has been
conducting an informal survey about the Star. The current
results are available in the file DUFFEY;APOLLO STARMS on MIT-AI
and the file <SROSS>STAR.MSS on MIT-XX. Please note that you do
not need to login to FTP the file from MIT-AI. People who cannot
obtain copies of the file themselves may request a copy of the
file by sending mail to APOLLO-REQUEST@AI.
Hank Dreifus <Dreifus at WHARTON> is conducting an initial
survey about the personal workstations people on this list
are using and/or developing. He would like to send him a
brief message describing the OA machine you use and why
(or why not). He will collect the responses and distribute
a final summary to the list.
A complete record of the APOLLO discussions will be maintained
in the file AI:DUFFEY;APOLLO ARCHIV. The archive is small now
because APOLLO is only a few days old. However, this will
change rapidly.
Comments in the ongoing discussions should be addressed to
APOLLO@MIT-AI. Administrative requests (eg. a message asking
to add someone to the mailing list) or questions about the
goals of this list should be addressed to APOLLO-REQUEST@MIT-AI.
Lastly, welcome to APOLLO. I trust you will enjoy being part of
these discussions.
Cheers,
Roger
Subject: Themes for discussion
∂11-Jun-81 0714 DREIFU at WHARTON-10 (Henry Dreifus) Themes for discussion
Date: 11 Jun 1981 (Thursday) 0915-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: APOLLO at MIT-AI
Some of the topics I would like to see discussed by this discussion
list are:
o Definition of a personal workstation.
o The IDEAL personal workstation.
o Technical review of all participating machines
where some accurate knowledge of the machine
can be presented.
o The introduction of personal workstations into large
business. The question of operational logistics,
transferring an application to a small machine.
o Is the right answer to make the small workstation
look like a very slow version of a large mainframe?
o Example applications.
o Trade offs in networking the workstations. Performance
weighed against cost and overhead.
o Some of the plans for introducing workstations in
operational areas.
o End user(s) of workstations, the application skewed
machines.
o User interfaces, factors.
------------------------------
There are but a few ideas. However one caveat. Facts are better
than Flames. Please no flaming, that is the one thing this list
is better off without.
Henry Dreifus
DREIFUS@WHARTON-10
-----
Subject: Preliminary results from the personal workstations survey
∂11-Jun-81 0735 DREIFU at WHARTON-10 (Henry Dreifus) Preliminary results from the personal workstations survey
Date: 11 Jun 1981 (Thursday) 0920-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: APOLLO at MIT-AI
Below is a condensed version of the various systems that people
have made an attempt to respond to. The interesting point(s)
that I have noticed are:
o Everyone's view of Personal Workstations is different.
o The machine(s) selected are wide ranged and apparently
well suited for each application chosen.
o There is no wrong Personal Workstation machine.
o The technology of Personal Workstations is not well
established as of yet.
o There is a demonstrated need for this technology,
it appears to be one year away from general use.
o Most have:
Large address space (or VM).
Networking capabilities.
Very good display hardware.
Large local storage capacity.
Micro-processor based.
Contain an external locator type input device.
o Most are missing:
Software tools to round out system.
Market recognition.
Gateway access, no gateway specifications.
Too many parts, development schedules are
full, revision schedules are bare.
Consistency. This is a result of different
definitions of what a personal workstation
is supposed to be.
------------------------------
Below is a summary of the survey responses. Eventually, each
machine will be examined in greater detail. The intention is
to educate ourselves about personal workstations. They sound
neat, but what they are under the surface is still a hot topic.
Machine Reason/Use Comments
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Perq Spice Project 15
Spice means: Scientific Personal Integrated Computing Environment.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Jericho BBN - Lisp machines 30
need large address
space and powerful
LISP processing.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
CTI For Alanthus. 16 workstations per
cluster capability.
(no numbers)
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
DEC-20/Ts computer Large Scale OA proj. 20
Interesting for discussion purposes.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Apollo Test/soft devt. 2 - max curr config.
existing in field
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Xerox Xerox Corp devt. 50-60
MIT, and others:
experimentation.
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Nu's MIT Workstation 15-25
prototype
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Wang WPS-25 Experiment 1-4
←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←←
Extending the survey:
Each technical group that has a machine; eg Xerox PARC,
please designate one person to introduce their machine(s)
with references in the literature. For each agency or
sponsored group, list the application and the reasons and
any other relevant information about their specific problem,
eg: general Office Management, or some application. This
should provide a good beginning in opening the discussions.
Henry Dreifus
DREIFUS@WHARTON-10
-----
Subject: personal computer economics
∂11-Jun-81 0759 Hank Walker at CMU-10A (C410DW60) personal computer economics
Date: 11 June 1981 1025-EDT (Thursday)
From: Hank Walker at CMU-10A (C410DW60)
To: apollo at MIT-AI
Most of the comments on the Xerox Star that have appearred in the paper say
something like "very nice...for half the price". VERY few companies have
computer capitalization that exceeds $10,000 per person. That's roughly
what it is at DEC (internal transfer cost), and the average outside company
would have to spend a lot more to reach the same level, which I consider
just adequate (terminal at home, one at work, access to several group
machines). The comments that I have heard from people in marketing are
that they don't think that large numbers of the Star will be sold to peons,
but rather to management types, who can use it as a status symbol.
So one requirement of a personal workstation that you are going to give
to everybody, including the secretaries, is a price of less than $10,000
including overhead from network, printer, file servers, etc. Also including
software.
Subject: Re: Another Xerox workstation.
∂11-Jun-81 1213 Charles B. Weinstock <Weinstock at SRI-KL> Re: Another Xerox workstation.
Date: 11 Jun 1981 1123-PDT
From: Charles B. Weinstock <Weinstock at SRI-KL>
To: TAW at SU-AI
cc: apollo at MIT-AI
In-Reply-To: Your message of 11-Jun-81 0918-PDT
The 820 (or Worm) is a 64k Z80 based machine that (at 3k) has a
keyboard, display, two mini-floppies, and can run either CP/M or
a Xerox hacked over Wordstar (this from the local representative).
The only current Ethernet capability is through a RS232 interface
(which means that an Apple or a Osborne has the same capability).
Xerox will have some sort of a real Ethernet available eventually.
According the the San Jose News of last night, the 820 has no
graphics capability. The main thing this @i[appears] to have going
for it is the Xerox name--many companies would rather deal with a
Xerox or an IBM than an Apple or a Radio Shack or a ...
The above is based on information gleaned from talking to various Xerox
people and is no doubt incomplete. I imagine there are Xeroxers on
this mailing list. Perhaps they can fill us in more.
-------
Subject: SAM/Worm/820
∂11-Jun-81 1241 Tom Wadlow <TAW at SU-AI> SAM/Worm/820
Date: 11 Jun 1981 1131-PDT
From: Tom Wadlow <TAW at SU-AI>
To: apollo at MIT-AI
Hopefully, Xerox will provide the software for the 820 to speak with Star
systems. That is where the 820 could have the advantage over the Apple
or Osbourne machines. I think that a lot of people who would like to
go into office automation are cringing at the price of the Star (when they
think of all the people that they would want on their office network).
If the 820 provides a thoughtfully designed subset of Star capabilities
(and I don't know whether it will or not) at a fraction of the price
it could be a wonderful bootstrapping mechanism for getting Ethernet
based systems into the offices. And you can always unplug the 820
and plug in a Star at a later date (perhaps allowing the employees
to take them home for telecommuting purposes).
Subject: personal computer economics
∂11-Jun-81 2242 Steven T. Kirsch <SK at MIT-MC> personal computer economics
Date: 12 June 1981 01:34-EDT
From: Steven T. Kirsch <SK at MIT-MC>
To: Hank Walker at CMU-10A
cc: apollo at MIT-AI
I think your argument is a little incomplete.
Suppose I make you the following deal: if you give me $10,000 today, I
will give you at least $5,000 every year for the next 5 years. I
think you will accept my deal, right?
Ok, now let's look at Star and suppose I can prove to you that it
makes me 10% more effective (this is hard to prove) or that it saves
me 10% of my time. My time actually costs the company $60,000 a year.
And I am but a lowly engineer making under $30K/year. So if the
if I do my work 10% faster, the company in some way, "saves"
$6,000/yr. (the savings could be in hiring less engineers or by
getting more work done per unit time or by getting the job done more
effectively).
In fact, the Booz-Allen study on the potential of office
automation (a very thorough case study of over 40 companies) concluded
the AVERAGE ROI on OA equipment was 86% annually and could be over
200% in some companies.
I think it is foolish to measure a system on cost. You measure on
price/performance or ROI. If Xerox can prove a high ROI, they will win.
I must work for one of those "VERY few" companies who spend over
$10,000 on computer equipment for engineers. It costs us $60,000 to
provide a computer port into our Data General Eclipse.
∂12-Jun-81 0051 Dave Dyer <DDYER at USC-ISIB> personal computer economics
Date: 12 Jun 1981 0043-PDT
From: Dave Dyer <DDYER at USC-ISIB>
Subject: personal computer economics
To: apollo at MIT-AI
While your fundamental argument is correct, you neglected two
important points.
First, the $10K (or whatever) is not free. At today's rates,
$10K capital investment costs the company 20% interest, either directly
because they had to borrow it, or indirectly, because they don't have
it to invest elsewhere. So your increase in productivity would have to
be at least 20% to break even.
Second, as someone else has pointed out, no one knows how to quantify
the increase (if any) in productivity from something like a star, especially
vis a vis similar software running on less flashy hardware. This makes
it impossible to "prove" any increase in productivity.
-------
Subject: personal computer economics
∂12-Jun-81 0051 Dave Dyer <DDYER at USC-ISIB> personal computer economics
Date: 12 Jun 1981 0043-PDT
From: Dave Dyer <DDYER at USC-ISIB>
To: apollo at MIT-AI
While your fundamental argument is correct, you neglected two
important points.
First, the $10K (or whatever) is not free. At today's rates,
$10K capital investment costs the company 20% interest, either directly
because they had to borrow it, or indirectly, because they don't have
it to invest elsewhere. So your increase in productivity would have to
be at least 20% to break even.
Second, as someone else has pointed out, no one knows how to quantify
the increase (if any) in productivity from something like a star, especially
vis a vis similar software running on less flashy hardware. This makes
it impossible to "prove" any increase in productivity.
-------
Subject: Subjective value of Personal Workstations
∂12-Jun-81 0447 Brian P. Lloyd <LLOYD at MIT-AI> Subjective value of Personal Workstations
Date: 12 June 1981 07:39-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: APOLLO at MIT-AI
Regardless of the arguments for and against the economic value of the
Personal Workstation (PW), the numbers are beginning to tell. I work
for Alanthus Data Communications and we market the Convergent
Technologies system to end users. Our marketing strategy is to point
out how the system provides OA, communications, and user
programmability in one box.
The response is overwhelming! The average configuration seems to be
going out at about $20,000 including software. Granted, at this point
in time people are buying development systems, but the availablity of
OA software (WP, mail, etc.) has been a driving point in almost every
sale.
Obviously people believe in the PW concept and the market is still
growing. Since people rarely exhibit rational behavior (except in a
negative [fiscal] sense), I don't expect rational decisions either way
on the subject. We all realize that OA and PWs are coming and noone
is going to stop it.
Since we all tend to be in areas of development for OA products, let
us now discuss what the needs of the user really are. Perhaps we can
decide what Office Automation and Personal Workstation really means.
Brian
Subject: Star/Mesa
∂12-Jun-81 0841 LYNCH at USC-ISIB Star/Mesa
Date: 12 Jun 1981 0819-PDT
From: LYNCH at USC-ISIB
To: Apollo at MIT-AI
The Star is almost useless to any of us who are doing computer
science R&D unless we can program it as we see fit. The applications
that Xerox has seen fit to release at this time are indeed quite nice
but do not justify the cost ($20K with software if you buy 50 or more
of them in a year's time -- they give a nice discount for volume
buys (about 25% off)). We asked Xerox to include Mesa.
They said OK. They have not yet quoted a price to us however.
We also asked for the microcode. Thye said Not at this time.
The Mesa release was contigent upon us buying a lot of them
(like 50-100). They are still confused about where their marketplace
is. If commerical orders do not flow in rapidly in the next
few months then they might be much more interested in
turning it into a "programmer's workstation" that would suit us.
WEe have also asked them to include much more memory on the Star.
They admit it can be done but that they are trying to build even
smaller confiturations of it (it currently comes with 384 MB).
Dan
-------
Subject: Star
∂12-Jun-81 0940 Tom Wadlow <TAW at SU-AI> Star
Date: 12 Jun 1981 0917-PDT
From: Tom Wadlow <TAW at SU-AI>
To: apollo at MIT-AI
As I understand it, the Star comes with a somewhat low-power programming
language called CUSP. This is the only programming facility available to
the user. Rumor has it (and it would not surprise me) that there is an
extensive Mesa development system that could be run on the Star, but is
destined to never leave the hallowed halls of Xerox. (If I am wrong
on any of this I will cheerfully accept correct information from our
friends at Xerox who are reading this)
Apparently the reasoning behind this involves consistancy in system
software. If you don't give the users (who aren't supposed to be
programmers to begin with) access to the system programming language,
and armor-plate the language that you do give them, they can't
do themselves or the system any harm. Also, if you want a new
system application, you must ask Xerox to make it for you. Thus
it will be written properly (I am not being sarcastic here. There
is a lot to be said for this approach when your target market is
composed of non-programmers). Xerox doesn't want to find themselves
in the position of supporting outside software, because outsiders
don't have the information and the methodology to write that
software in a consistant manner with the rest of the Star system.
[Subj: Mesa language, PDP10, etc]
∂12-Jun-81 2016 Ian H. Merritt <MERRITT at USC-ISIB>
Date: 12 Jun 1981 1529-PDT
From: Ian H. Merritt <MERRITT at USC-ISIB>
To: CSVAX.fateman at BERKELEY
cc: apollo at MIT-AI, MERRITT at USC-ISIB
In-Reply-To: Your message of 12-Jun-81 0736-PDT
The major problem we have encountered at ISI is not the hardware costs, but
unwillingness of Xerox to supply us with the facilities to write our own
system software. The eventual availability of the Mesa language has been
discussed, but we need all the system software in order to configure the
system to be useful for our applications.
Another consideration is the internet protocols which are (as I am led to
believe) currently not supported.
The idea of using PDP-10s as 'glorified file servers' has been discussed
and seems to be the best way to proceed, since there is currently no part
of the product line which will afford us the massive storage and archival
system we require.
<>IHM<>
-------
Subject: Re: Speaking up Xerox!
∂12-Jun-81 2037 Hamilton.ES at PARC-MAXC Re: Speaking up Xerox!
Date: 12-Jun-81 16:32:59 PDT (Friday)
From: Hamilton.ES at PARC-MAXC
In-reply-to: GEOFF's message of 12 Jun 1981 1421-PDT, <[SRI-CSL]12-Jun-81 14:21:10.GEOFF>
To: Geoff at SRI-CSL
cc: Apollo@AI, Hamilton.ES
We (Xeroids) have been informed that "according to Xerox management,
Xerox policy is to send NO information on Xerox products over the
Arpanet. Thus, APOLLO should be considered to be one-way (inward
only) with regard to Xerox products."
I'm just a low man on the totem pole, so I speak only for myself,
but I suspect that there are two concerns here. One is that we
don't want to do anything that could be construed as "selling"
(even if only as a passive response to people's technical questions)
over the net. The other is that we insiders tend to lose track
of what's officially announced and what isn't, and what's part of
our product as opposed to our development environment.
I certainly encourage other Arpanet sites to share their perceptions
and expectations of Star. Doubtless such reactions will be one of
many valuable sources of input to determine the product's future.
--Bruce
Subject: Workstations, and their posts.
∂12-Jun-81 2244 DREIFU at WHARTON-10 (Henry Dreifus) Workstations, and their posts.
Date: 12 Jun 1981 (Friday) 2233-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: apollo at MIT-AI
User interface, how important?
The Apollo has nothing right at the moment, as compared to the Star, in
which almost the total software engineering effort has been skewed.
Building a powerful user interface is ''nice'', but what is left
with respect to processor cycles is not so ''nice''. The questions of
priorities for any given application is not clear.
Example:
o Personal workstations are purchased because;
(a) Small application program needs to be run off mainframe
(b) Office - management systems need more sophistication
(c) Need for specialized computing has grown
(d) Corporations can no longer shell out vast sums of
money on computing, when distributing is available.
o What personalities should personal workstations have?
In answering this, there are basically 2, a truely split
personality:
Consider:
System FOO runs on giant IBM-303x and can really be run on
lots of distributed perscoms [from G. Steckel].
Systems people would like to see a very interactive and
totally controllable system, perhaps right down to the
micro-code. The full power, memory management right through
to the disk-I/O routines. Engineering a product right is
as equivalent to engineering it well.
Management would want to see just the pretty pictures, the
finished product, none of the rough edges, that the software
engineers love to play with. All they want is a black box with
none of the 'hassles' of low level code.
A split personality indeed.
Most systems are geared towards the management. The fact that
few provisions have been made for the systems types is indeed a
potential tragedy. Much of the insulation is hindering a good job for
the programmer. Remember these things are nothing more powerful than
your Apple computer, doing a major application in-efficiently will hurt
the perscoms in the long run.
Opinions?
/Hank
Subject: correction on dlw's message
∂13-Jun-81 1122 CSVAX.halbert at Berkeley correction on dlw's message
Date: 13 Jun 1981 10:32:20-PDT
From: CSVAX.halbert at Berkeley
To: apollo@mit-ai
The Xerox Star does have virtual memory; it does page.
--Dan
∂13-Jun-81 1151 LYNCH at USC-ISIB Re: correction on dlw's message
Date: 13 Jun 1981 1144-PDT
From: LYNCH at USC-ISIB
Subject: Re: correction on dlw's message
To: CSVAX.halbert at BERKELEY, apollo at MIT-AI
cc: LYNCH
In response to the message sent 13 Jun 1981 10:32:20-PDT from CSVAX.halbert@Berkeley
But I have heard the paging on the Star is a terrible crock:
it does it by double lookup on every memory reference way down
in the microcode. At this time it has no hardware to assist
paging (like associative memory for the TLAs) or even a
kludge like KL-10s have. The (mis)feature makes it tough
to imaging the STar as a LISP machine host.
Dan
-------
∂13-Jun-81 1236 mike at RAND-UNIX MESA on Star
Date: Saturday, 13 Jun 1981 12:18-PDT
To: apollo at MIT-AI
Subject: MESA on Star
From: mike at RAND-UNIX
I have heard a rumor, from a source I trust, that MESA will be
available to those who buy 50 or more Star's. I do not know if there
will be a heavy price, nor do I know if this is a special deal to non-
profit or educational institutions or special in some other way.
There is someone on this list -- you know who you are -- who can
confirm or deny this rumor authoritatively if he chooses to.
In any case, I believe that MESA is a good systems programming
language, but you can certainly kiss portability goodbye!
Subject: Acquiring personal computers
∂13-Jun-81 1415 Sam.Harbison at CMU-10A Acquiring personal computers
Date: 13 June 1981 1534-EDT (Saturday)
From: Sam.Harbison at CMU-10A
To: apollo at mit-mc
Message-Id: <13Jun81 153417 SH01@CMU-10A>
There's been a lot of discussion about the pro's and con's of various personal
computers/personal workstations. Let me give a brief summary of some decisions
taken at CMU.
About two years ago, the CS department decided that our long-term computing
needs would be best met by a network of personal computers in offices, and
plans were made to embark on a research project (Spice) that would give us by
1985 the kind of software necessary for such an facility (including Lisp and
Ada programming environments, document production environments, and multi-media
communication). We thought that it would be 1985 before personal computers
appeared with the right power and cost. Because we did not want to do any
hardware design, we began to canvas manufacturers to see 1) what was available
now to start with, and 2) what might be available in 1985.
The machines close enough to what we wanted to act as a prototype were Perqs,
Apollos, Lisp Machines, Nu Machines, and Xerox D-machines (Dolphin, Dorado, and
the Star computer). Our principal criteria were that the machine had to have
all the basic features of a 'real' machine (display, net, etc.) and be flexible
enough to allow us to develop software for the 1985 machines now. Furthermore,
it was important that we be able to distribute our software to other people.
To make a long story short, Apollos and Nus did not have the writable
microstore that we considered critical, and their microprocessors did not seem
to be able to support the kind of multiprogramming we wanted. Lisp Machines
were too expensive and production (then) uncertain. Xerox and their machines
were philosophically close to us, but the Dolphin/Dorado were not commercial
products, and Xerox would not commit to releasing Mesa, meaning that we might
find it difficult to distribute a system built in Mesa. We finally chose to
begin with Perqs, which on paper are at least equal in performance to any of
the others except the Dorado and Lisp Machine. (And which can be
microprogrammed to be very much like the machine we really want, except for
performance.) The Star's advantage quoted by others is, I think, due to
software refinement. We now have fifteen Perqs at CMU, and work on Spice is
proceeding rapidly. We continue to be on the lookout for new hardware that can
be used in the Spice system in years to come.
Our criteria for machines may not be the same as other people's; we are heavily
committed to "high-end" personal computers, and the software available was
relatively unimportant to us. However, if Mesa and its compilers were freely
available the Xerox machines would have been very attractive.
Subject: Arpanet usage
∂17-Jun-81 0551 Liddle at PARC-MAXC Arpanet usage
Date: 16 Jun 1981 17:45 PDT
From: Liddle at PARC-MAXC
To: AllDLOS↑.DLOS, AllEOS↑.EOS, AllES↑.ES, AllHENR↑.HENR, AllPA↑.PA,
AllWBST↑.WBST, AllXRCC↑.XRCC
cc: Apollo at MIT-AI, Liddle
Many of you in Xerox are aware of a newly created Arpanet distribution list
named Apollo. It was established to promote discussion of personal workstation
computers. As you might expect, much of the recent discussion has involved the
Xerox 8010 Star information system. Because many of the messages ask for
information about this product and its associated development software, you may
feel tempted to reply to some of them.
It is ARPA policy that the Arpanet be used only for government supported
research and development. It is against Xerox policy to use the Arpanet to discuss
products. It is completely inappropriate to use the Arpanet in a way that may be
construed as selling or promoting a Xerox product (or future product). Xerox
employees use the Arpanet for ARPA related research purposes only, not for
answering questions or distributing information about our products.
Questions from potential customers about the Xerox 8010 and other OPD products
should be referred to Arnold Palmer, Field Sales Manager, Xerox Corporation,
1341 West Mockingbird Lane, Dallas, Texas 75247, phone (214) 689-6689.
David E. Liddle
Vice President
Office Products Division
Subject: Stars in the sky
∂19-Jun-81 0555 mo at LBL-UNIX (Mike O'Dell) Stars in the sky
Date: 17 Jun 1981 09:15:54-PDT
From: mo at LBL-UNIX (Mike O'Dell)
To: info-micro at mit-ai
Redistributed-To: WorkS at AI
Redistributed-By: GEOFF at SRI-CSL
Redistributed-Date: 17 Jun 1981
Last week we had a briefing on the Star, so I will relate what was said.
The processor is a D3 machine, and is claimed to run Mesa about
3 times faster than a D0 or a Dolphin. The D3 is a 32-bit, virtual
memory design. The Star only has about 200kb
of memory on it, expandable to about .5 megs, but there is every
reason to believe it can have a lot more than that on it. The
office automation software is all written in Mesa and the base of
the machine is Pilot, but you can't get to any of this. The is a lot
of discussion about making the Mesa environment available, but so
far there is a negative corporate attitude. If they would just
realize how neat that would be.... Anyway, the office software is
pretty classy, but their pricing is repressive. By the time you
license all the software (math editor, graphics, spelling corrector, etc),
which must be done for EACH machine, you add about $5K to the price.
The killer, however, is software maintenance for that machine will
be close to $500 per month!!!!! The pricing structure allows hardware
quantity levels to count the various servers (com, file, print, etc)
as well as Stars because they all use the same CPU box, but
quantity levels for software count only Stars. Software for the
other servers is priced the same way. The basic file server does NOT
come with the electronic mail facility. That handy option costs extra.
Rumors abound pertaining to the transport of Smalltalk and Interlisp
to the machine, but like with Mesa, Xerox doesn't see any demand for
user programmable machines. Moreover, if they can continually
squeeze money out of you for software, it is to their advantage
that no one else can build software for it. (Personal comment)
If any mere mortal (other than MIT, CMU, and Stanford) can
shake Mesa out of Xerox, let me know.
-Mike
Subject: Productivity gains without using workstations
∂24-Jun-81 0511 DPR at MIT-XX Productivity gains without using workstations
Date: Tuesday, 23 June 1981 10:02-EDT
From: DPR at MIT-XX
To: WORKS at MIT-MC
Kirsch has an extremely valid point. The fundamental question is what
leverage does computerization provide in doing a function. However, let's
not be miserly--even Xerox STAR's are incredibly cheap as an investment,
so the amount of leverage they must provide is small.
Personally, I think companies with cash to invest ought to invest it
in ecnomic sectors of maximum productivity gain--however, there are
immense barriers to this. Most companies restrict themselves to internal
reinvestment of their funds. Since our largest and least productive
companies have the higher percentages of funds to invest, and since they
are largely white-collar offices, there is a great move toward
office automation, even though productivity gains are slim in most
office applications.
The sterling exception to this observation about the utility of workstations
lies in tools of high leverage like VisiCalc--which make order of magnitude
changes in labor required to do a task. The Star seems to be able to do this
with the production of business graphics--but I am not sure that they
will be largely used in this domain, or if the graphics thus produced
would have been produced had there not been a Star.
Subject: Star Info
∂24-Jun-81 0533 UOFILLINOIS at WPAFB-AFWAL Star Info
Date: 23 Jun 1981 (Tuesday) 1419-EDT
From: UOFILLINOIS at WPAFB-AFWAL
To: works at MIT-AI
cc: gdh at MIT-AI
The STAR people came here to talk today.
Here's some facts/rumors that were new
to me:
o Mesa will probably be released for
the STAR either the 4th quarter of
this year or the 2nd quarter of next
year.
o Smalltalk "will NOT be released on the
STAR or anywhere else" -- a "small
outfit in Silicon Valley" (not PARC --
I'm not sure who they're talking about)
licensed it to HP, TI, and Apple. When
the STAR marketing people found out,
they "put a stop to it"
o A personal computer called the "inch-
worm" will apparently be announced
soon. It is about book-sized, has
a bitmapped display, and measures
about an inch thick (hence the name).
Could this be a first pass at the
Dynabook?
o They won't sell just one STAR until
next year
-geo
Subject: Re: Apollo Network
∂24-Jun-81 0554 mike at RAND-UNIX Re: Apollo Network
Date: Tuesday, 23 Jun 1981 10:39-PDT
To: Eric Benson <BENSON at UTAH-20>
Cc: WorkS at MIT-ML, DLW at MIT-AI
In-reply-to: Your message of 22 Jun 1981 1043-MDT.
From: mike at RAND-UNIX
You say that the 'apollo software is another story'.
Well, OK, what's the story?
When I was visiting Apollo, it was clear that the hardware was close
to working and that they had no idea just how hard the software they
were planning was going to be to write. Either they didnt know or
they were trying to tell me a story.
Specifically, they intended to write a truly network distributed file
system: with paging, swapping and file transfers all completely
independant of the local machine which might or might not have a disk
drive. When I asked them what file names would look like, to get an
idea of whether the file name would contain the name of the root file
system (location) or whether the location would be 'hidden' from the
user: they had no idea. They had never even thought of the question.
It is possible that there was someone in the building who knew
something about software, but I didnt have the opportunity to meet
them.
I was also not overwhelmed with their desire to build a non-standard
network. But their attitude seemed to be: this is what Prime is doing
and we are really from Prime so this is what we are doing.
Update ??
∂24-Jun-81 0606 Dave Crocker <dcrocker@udel> Apollo gatewaying
Date: 23 Jun 81 11:11:25-EDT (Tue)
From: Dave Crocker <dcrocker@udel>
To: Works at Mit-Ai
Subject: Apollo gatewaying
We had an Apollo presentation, given by Dave Nelson, one of
their Development VPs. He said that a gateway (to unspecified
other networks) was planned. Guess I would expect the initial
one to be to others of their (Domain) rings.
It was my impression that the basic network environment is
strictly message/packet oriented, without connections or other
efficiency mechanisms. Nelson pointedly stated (it was too
affirmative to class as an "admission") that they were not
oriented toward file transfers . Such things can and are done,
but the environment is not tuned to them.
Dave
∂24-Jun-81 0617 DREIFU at WHARTON-10 (Henry Dreifus) Quick overview/summary: The Apollo-I (Domain) computer.
Date: 23 Jun 1981 (Tuesday) 2308-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Quick overview/summary: The Apollo-I (Domain) computer.
To: WorkS at MIT-AI
The structure of the Apollo computer network:
--- --------- -- --- ------ -------- --------
Summary:
o ~~ 12 Mbit bandwidth
o standard Coaxial RG58 cable
o Ring structure, single band.
o Token passing [Cambridge Ring Network concept]
Fixed packet sizes [I believe 4K bytes] are constructed for
transmission from one "node" to another. A "node" consists of a
68000 and a winchester disk drive.
∂24-Jun-81 0627 Griss at UTAH-20 (Martin.Griss) More on DOMAIN
Date: 23 Jun 1981 0741-MDT
From: Griss at UTAH-20 (Martin.Griss)
Subject: More on DOMAIN
To: Works at MIT-ML
cc: griss at UTAH-20
Discussions we have had with Apollo indicate that they are aware of the
MultiBus Ethernet board, and certainly plan to use the MUltiBus crate for this
level of I/O support board (NOT MultiMaster usage); my guess is that one of the
university people with an Apollo is likely to try to do the Ethernet Interface
software, most likely after a C is working. Any comments from Brown U. ?
M
-------
Subject: Quick overview/summary: The Apollo-I (Domain) computer.
∂24-Jun-81 0617 DREIFU at WHARTON-10 (Henry Dreifus) Quick overview/summary: The Apollo-I (Domain) computer.
Date: 23 Jun 1981 (Tuesday) 2308-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: WorkS at MIT-AI
The structure of the Apollo computer network:
--- --------- -- --- ------ -------- --------
Summary:
o ~~ 12 Mbit bandwidth
o standard Coaxial RG58 cable
o Ring structure, single band.
o Token passing [Cambridge Ring Network concept]
Fixed packet sizes [I believe 4K bytes] are constructed for
transmission from one "node" to another. A "node" consists of a
68000 and a winchester disk drive.
∂24-Jun-81 0627 Griss at UTAH-20 (Martin.Griss) More on DOMAIN
Date: 23 Jun 1981 0741-MDT
From: Griss at UTAH-20 (Martin.Griss)
Subject: More on DOMAIN
To: Works at MIT-ML
cc: griss at UTAH-20
Discussions we have had with Apollo indicate that they are aware of the
MultiBus Ethernet board, and certainly plan to use the MUltiBus crate for this
level of I/O support board (NOT MultiMaster usage); my guess is that one of the
university people with an Apollo is likely to try to do the Ethernet Interface
software, most likely after a C is working. Any comments from Brown U. ?
M
-------
Subject: Re: Star Info
∂24-Jun-81 1838 Deutsch at PARC-MAXC Re: Star Info
Date: 24 Jun 1981 10:17 PDT
From: Deutsch at PARC-MAXC
In-reply-to: UOFILLINOIS' message of 23 Jun 1981 (Tuesday) 1419-EDT
To: UOFILLINOIS at WPAFB-AFWAL
cc: works at MIT-AI, gdh at MIT-AI
I would like to correct some erroneous information about Smalltalk and the Star.
o Smalltalk "will NOT be released on the
STAR or anywhere else" -- a "small
outfit in Silicon Valley" (not PARC --
I'm not sure who they're talking about)
licensed it to HP, TI, and Apple. When
the STAR marketing people found out,
they "put a stop to it"
The truth is that LRG, a group within PARC, has licensed Smalltalk-80 (the only
Xerox-authorized version of Smalltalk to be released) to a number of micro- and
mini-computer manufacturers. The release consists of detailed specifications for
the machine-dependent kernel, plus a mag tape containing the rest of the system
(windows, editor, compiler, file system, etc., etc.) Several of these manufacturers
have made excellent progress on implementing the system, to the point of having
windows appear on their displays. I can't comment on the specific list of
manufacturers, since we prefer to let them make their own announcements. The
Star marketing people have not exerted any pressure in either direction with
respect to this; the release/license process was properly cleared with our legal
department and all relevant product organizations within Xerox, and we are
currently working out ways to license the system to manufacturers (and
universities) beyond the original group. I can't comment on the availability of
Smalltalk for the Star, except to say that the Star hardware is definitely powerful
enough to support Smalltalk.
Subject: Re: Star Info/Smalltalk
∂24-Jun-81 1911 Ron Newman <Newman.es@Parc-Maxc> Re: Star Info/Smalltalk
Sender: Newman.ES at PARC-MAXC
Date: 24-Jun-81 9:48:22 PDT (Wednesday)
In-reply-to: UOFILLINOIS' message of 23 Jun 1981 (Tuesday) 1419-EDT
From: Ron Newman <Newman.es@Parc-Maxc>
To: UOFILLINOIS at WPAFB-AFWAL
cc: Newman.es, works at MIT-AI, gdh at MIT-AI
Who were "the STAR people" that came to talk to you?
Smalltalk IS being released by PARC this summer. There was a big presentation
on the subject at this year's NCC. Apple, DEC, HP and other companies are
doing research into implementing it on their machines. (In fact, one of the
primary Smalltalk implementors, Larry Tesler, is now at Apple and was one of
the speakers at NCC.) A huge article on the subject will appear in the
August issue of BYTE.
The deal is that PARC gives you an "image" file on a tape, whichcontains
all of Smalltalk ready to run. To run it, you have to implement an
interpreter on your machine for the 256 Smalltalk bytecodes. Just like you
can run Pascal, if you have a P-code interpreter.
(I don't think anyone at Xerox will beat up on me for this message; all of
it comes from strictly public sources.)
/Ron
Subject: Re: Smalltalk
∂24-Jun-81 1951 mike at RAND-UNIX Re: Smalltalk
Date: Wednesday, 24 Jun 1981 11:45-PDT
To: WorkS at MIT-AI
From: mike at RAND-UNIX
Forgetting for a moment about Xerox marketting, Xerox intends to
release a book on Smalltalk called Smalltalk 80. This version of
Smalltalk is intended to be easily portable. There was some
discussion within Xerox legal about whether the Smalltalk virtual
image would be released. But the book which describes the interpreter
plus the virtual image would result in a very easily portable
language.
One could then port it to the machine of your choice, including the
STAR, assuming that you could PROGRAM the STAR. When MESA gets
released you will be able to implement it in that: but a better place
is microcode. I haven't heard anything definitive about whether Xerox
intends to microcode the Dandelion (STAR workstation) for Smalltalk.
Xerox marketing wasn't trying to mislead, I'm sure. They have no
interest in marketing Smalltalk; just word processing.
Michael
Subject: Chromatics
∂24-Jun-81 2036 cfh at CCA-UNIX (Christopher Herot) Chromatics
Date: 24 Jun 1981 10:39:46-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: WorkS at mit-ai
I saw the Chromatics CGC 7900 "Color Graphics Computer" at
the National Computer Graphics Association show last week.
It's hardware is:
Motorola 68000
1024 x 768 x 8 bit color display w/24 bit lookup table
10Mb Winchester disk
Dual Floppies
Light Pen
Joy Stick
151 (I'm not kidding) Key Keyboard
Prices range from $25,000 to $50,000 depending on how much memory
and other options you buy. It doesn't have virtual memory like
the Apollo but can take quite a bit (at least a meg) of real memory.
They plan on supporting IDRIS, a UNIX clone, sometime soon.
Address:
Chromatics, Inc.
2558 Mountain Industrial Boulevard
Tucker, Georgia 30084
404-493-7000
∂24-Jun-81 2052 guyton at RAND-UNIX Re: Chromatics Personal Workstation
Date: Wednesday, 24 Jun 1981 16:13-PDT
To: PRSPOOL at RUTGERS
Cc: WorkS at MIT-AI
Subject: Re: Chromatics Personal Workstation
In-reply-to: Your message of 23 Jun 1981 1139-EDT.
From: guyton at RAND-UNIX
The Chromatic 7900 workstation has been announced for a while now and they
had one at the Chicago NCC. Their address/phone:
Chromatics
2558 Mountain Industrial Boulevard
Tucker, Georgia 30084
(404)493-7000
Here a few facts off their CGC 7900 literature:
16-Bit processor (MC68000)
19" color monitor
1024x768 viewable bitmap (in a 1024x1024 bitmap memory)
Up to 256 simultaneously displayed colors
Palette of over 16 million colors (i.e. 8-bit DAC for RGB)
10MB Fixed Winchester Disk (8.4 MB formatted)
Dual floppies
light pen, joystick
Maximum of 16-bitmap planes (no more than 8 displayed at once)
Maximum of 2MB of processor memory
Rand reviewed this machine last year and might have purchased one if it
hadn't been quite so new (at the time they had not delivered any, and we
needed a mature system). When I priced it, a useful system was running
around $60K.
Oh yes, they're planning on running the 68000 unix look-alike.
Jim
∂24-Jun-81 2109 Robert A. Morris <RAM at MIT-MC> Chromatics Personal Workstation
Date: 24 June 1981 18:57-EDT
From: Robert A. Morris <RAM at MIT-MC>
Subject: Chromatics Personal Workstation
To: PRSPOOL at RUTGERS
cc: WorkS at MIT-AI
According to a sales engineer I spoke to in Atlanta las week, the software is
IDRIS, Whitesmith's UNIX look alike, none of which had yet been
dleivered to them (or any one else???), nor could he say when an
order placed for the IDRIS software for Chromatics be filled.
If color isn't mandatory and if you are willing to think about systems
with not yet ready software, ask Three Rivers whether/when the Tom Duff
port of Coherent, the Mark WIlliams company version 7 unix look-alike,
will be sold for PERQ's
--bob morris
p.s. A great deal of the Apollo software is also "not quite ready" but
they at least don't advertise it. It's just that Apollo's will presently
do much less than the world of WorkS expects them to. I will flame
after some less biased view of this week's Brown University
Apollo Users workshop appears in this forum.
Subject: Burroughs OFIS products
∂25-Jun-81 0537 Mike Leavitt <LEAVITT at USC-ISI> Burroughs OFIS products
Date: 24 Jun 1981 1748-PDT
Sender: LEAVITT at USC-ISI
From: Mike Leavitt <LEAVITT at USC-ISI>
To: works at AI
Message-ID: <[USC-ISI]24-Jun-81 17:48:50.LEAVITT>
The following is an excerpt from the New York Times, 6/23/81,
p. D5
"The Burroughs Corporation moved more aggressively into the
market for the automated office yesterday with the introduction
of a new type of information processing system that can be used
by managers and other professionals with no computer training.
"The system, called OFIS 1 Information Systems, connects
various electronic office machines together and allows them to
communicate. It includes such functions as word processing,
automatic filing and retrieval of business information and
electronic mail communications. . . .
"The system competes head-on with automated office systems
introduced in recent months by IBM, the Datapoint Corporation
and Xerox, and will be compatible with electronic equipment
made by other manufacturers. One shortcoming, according to
some analysts, is that the new system will not be able to
generate and display graphics. But the analysts were unable
to provide detailed comparisons with the competitors' systems.
. . .
"The most important innovation is a component of the OFIS
1 system called OFISfile, which permits up to 80,000 [Sic]
pages of text to be filed automatically and retrieved on
demand. OFISfile was designed to locate any document or group of
related documents with nothing more than an instruction phrased
in common English and containing a name, date, or other words in
the text being sought. . . .
"The basic OFISfile sells for $59,400, while prices for
the OFISdirector, the information processor that permits
system components to communicate with each other, starts at
$33,500. The company said that initial deliveries for the new
system are scheduled for this fall."
Burroughs?????
Mike
Subject: Re: Works: Re RIvanciw: OA Architecture
∂25-Jun-81 0600 Rivanciw at Darcom-HQ Re: Works: Re RIvanciw: OA Architecture
Date: 24 Jun 81 15:52:56-EDT (Wed)
From: Rivanciw at Darcom-HQ
To: Barns at Office-2
cc: Works at Mit-Ml, Barns at Office-2,
cc: UDel.POBox; 17 Jun 81 9:16-EDT at Office-2
Via: Darcom-HQ; 25 Jun 81 0:01-EDT
I will restate my case for the development of a systems architecture
as an early step in addressing the issue of office automation.
I will restate my position with some real world truths here at DARCOM.
It is possible at DARCOM to have office automation services for a
one time cost as low as $5634.00. That full purchase price for 100%
availability on a micro computer. Since most folks currently operate
in a timesharing mode with a multitude of user via for available ports
on a given machine, 100% availability is a step up. This price will
continue to drop as technology moves forward.
That system is based on an 8 user micro supporting 8 users. There are
8 ports on that micro so every user can run her/his office tools
whenever they want. They can currently run a host of tools including
a word processor, 3 different mail systems, a calendar system, a suspense
tool, a tickler system, a conference scheduler, a phone directory, a
reminder services, automated weekly activity reporting, and a couple
of other tools integral to the office.
Since most folks entering the realm of office automation do not use
their system for 8 hours a day, it is most acceptable that a micro with
8 user ports could easily support 16 office workers. Thus the cost
of that system is now $2817.00 one time purchase cost. On a lease that
price would be somewhere around $1000.00 or less a year cost per user
for full office automation tool usage. Now even the most pessimistic
predictions about the field of office automation would conclude that
a grand/year is very, very cost effective.
We are able to offer these cost effective systems because we have an
architecture.
As for being limited to 64K core, what micros are you looking at? The
last one I took delivery on had 1MB core. It was running a full
version 7 of UNIX plus all the software I mentioned above with 8 users.
Randy Ivanciw
Subject: Apollo files and network
∂25-Jun-81 0730 cfh at CCA-UNIX (Christopher Herot) Apollo files and network
Date: 24 Jun 1981 10:14:53-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: WorkS at mit-ai
When I last played with an Apollo a few weeks ago, it appeared
to have a hierarchical file structure very similar to UNIX.
The operating system treats local files and files on other
nodes of the ring net identically, e.g. you can copy a file
from one machine to another by typing
copy //mike/foo/bar //mary/foo/bar
and can do any file operation without respect to which machine
the file lives on. As I recall, a single slash at the beginning
of a file name indicated a pathname relative to the local node,
while two slashes indicated a pathname rooted in some master node
for the entire network. Hopefully someone at MIT, Harvard, or
Brown can elaborate (or correct).
Apollo claims that local and network file access are within
a factor of two of each other in speed. Neither appeared
particularly fast in the preliminary version I saw.
Subject: Comment on note on Apollo Network
∂25-Jun-81 0754 Dave Farber <farber@udel> Comment on note on Apollo Network
Date: 25 Jun 81 5:35:03-EDT (Thu)
From: Dave Farber <farber@udel>
To: works at Mit-Ai
The Apollo network is a token network as stated. However the
Cambridge folk are not the originators of the token ring idea. In
fact the Cambridge ring is NOT a token ring. It is a slotted ring
with small slot size.
Tokens rings come via Newhall/Farmer - the DCS process addressed
ring (the first with a real token) - the LNI/MIT LCS I ring with
the Prime ring being derived from the DCS instance.
Dave
Subject: Re: Quick overview/summary: The Apollo-I (Domain) computer.
∂25-Jun-81 0822 SHOCH at PARC-MAXC Re: Quick overview/summary: The Apollo-I (Domain) computer.
Date: 24 JUN 1981 1730-PDT
From: SHOCH at PARC-MAXC
To: DREIFU at WHARTON-10, WorkS at MIT-AI
cc: SHOCH
In response to the message sent 23 Jun 1981 (Tuesday) 2308-EDT from DREIFU@WHARTON-10
One fine point on local networks:
a) The ring produced by Prime Computer is a "token passing" design,
and it appears that the Apollo system follows this design.
Token passing systems trace their roots back to the work of
Newhall and Farmer at Bell Labs.
b) A recent message suggested that the Cambridge Ring
was also in this family; however, that design would more properly
be described as an "empty slot" ring. The empty slot systems trace
their roots back to the work of Pierce, et al., also at Bell Labs.
John Shoch
[PS: For more than you ever wanted to know on this subject, interested
readers might like to consult the "Annotated bibliography on local
computer networks, third edition," April 1980, Xerox Parc Report
SSL 80-2. Also available as IFIP Working Group 6.4 Working Paper 80-12.]
Subject: APOLLO net
∂25-Jun-81 1602 Griss at UTAH-20 (Martin.Griss) APOLLO net
Date: 25 Jun 1981 1021-MDT
From: Griss at UTAH-20 (Martin.Griss)
To: WORKS at MIT-AI
cc: griss at UTAH-20
I have seen a two node configuration of Apollo's working (Mountain View
Branch), and was able to see a file shipped from one node to the other,
and to compare the times required to count the number of lines
in the local copy and also in the remote copy, accessed via "//<host>file..".
It was interesting that in the first test, the times local and remote
were essentially; after a reboot, the remote time increased slightly
(about 5%). This was explained as an effect of the Unique global ID; in
the first test, the system "knew" the local and remote file by the same
Global ID, and also that the local copy was in the Memory space.
I do not recall the exact number of lines (it was a LARGE file), and the
time was about 1minute. The timing was done by submitting to the
SHell the concatenated commands:
time; countlines //host/... ; time; (This is NOT verbatim).
We also saw the multiple INPUT/OUTPUT windows and PADs working, the
various Display Manager options, the ability to Grow and Shrink windows,
the ability to run separate processes in each Window (in this case,
it was Edit in one, LIST in the other, as I recall).
We were not able to see any real graphics (ie line drawing), tho a small
program was demonstrated that was able to BLT screen areas around.
Martin Griss
-------
Subject: My CT system configuration and Chromatics
∂25-Jun-81 1657 Brian P. Lloyd <LLOYD at MIT-AI> My CT system configuration and Chromatics
Date: 25 June 1981 08:29-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Bruce Daniels wrote asking about the configuration of my CT system at
home. Here is what I have:
Workstation with 256Kb RAM, 5Mhz 8086, 2xRS-232, Centronics
printer port
10Mb 8" winchester (Shugart 1004 drive)
0.5Mb 8" floppy (single side, double density Shugart 800
drive)
Soon to be added (awaiting delivery only):
Additional Workstation to be clustered on the first using CT's
local network (multi-drop, 615Kbaud, half-duplex, RS-422 line)
GE 510 300lpm printer
For software I have:
CTOS multi-task, real-time OS
Pascal
FORTRAN
Word Processor
ISAM
Forms
Sort/Merge
Multiple-window Screen-oriented text editor
Basic
and several programs of my and others design...
For those of you used to home computer prices you may find things just
a bit steep, but if you compare performance per dollar it seems to be
a fairly good deal. Price for a 128K dual floppy system is $13,300 in
unit quantities. The 256K winchester system comes in at about $21,000.
All stand-alone systems include OS (linker, assembler, screen-oriented
editor, and asynchronous terminal emulator). Additional workstations
go for $6,490 for a 128K version or $7,900 for a 256K version.
I like the system a lot. It is easier to use/develop software for
than my PDP-11/23 with RSTS/E was (I know most of you are UNIX hackers
but you have to take what you can get).
Brian
Subject: Re: Personal Workstations -- who for?
∂26-Jun-81 0604 Rivanciw.DHQ at UDel Re: Personal Workstations -- who for?
Date: 25 Jun 81 8:26:40-EDT (Thu)
From: Rivanciw.DHQ at UDel
To: JWALKER at Bbna
cc: WorkS at Mit-Ai
Subject: el.POBox; 19 Jun 81 7:36-EDT
Via: Darcom-HQ; 25 Jun 81 8:26-EDT
I agree wholeheartedly with the comments put forth in JWALKER's
message on Personal Workstations -- who for?
There currently seems to be one of two approaches taken in
applications for office automation:
(1) Develop an application that answers a specific
functional requirement. For example, a budget
preparation tool or a project management (pert)
tool. JWALKER is very right in stating that all
to often these applications are written FOR the
functional and indeed do narrowly define the scope
and processes of usually complex functions. What
results is an application that does not quite do the
job and is too inflexible to mold to the nuances
of the functional task which it attempts to address.
Bottom line is that the functional user must adapt
the way she/he does business to the application.
(2) Develop a general tool (or set of tools) that can
be used in a wide range of functional applications.
Here I am speaking of a message system, and editor,
a suspense tool, etc. While these give the functional
user much more flexibility on how she/he will use
the tool in his/he job, often this adaptation is
cumbersome. Many time we have given a message system
to a user with the response being "What can I use this
for in my job?" Then we explain how and they ask why
and we explain more and they ask how and why and....
Thus we seem once again to be telling them how to do
their business.
The folks here in are branch spent an entire day discussing this
very problem last week. What we came up with was that there is
a need for general tools AND a need for specific applications.
The problem really is that we are addressing office automation
as a tool or an application and it is really much richer than
a single tool (or set) or a single application.
What we are planning to do is to develop an office automation
system which puts emphasis on the work ENVIRONMENT. We are
going to try to structure the user's terminal like a desk.
For example, when they reach for their inbox they will end
up in the mail system. If they suddenly get a call in the middle
of reading their inbox they will not have to exit the
mail system to get to their telephone pad or calendar or whatever.
They will simply reach for it. The system will suspend processing
in the inbox and move to the telephone pad or whatever the user
wants. At the conclusion of the telephone call the user will
say something like "continue" (or hit a button) and the system
will remember where he/she was in the inbox.
In this type of environment tools and applications are transparent
to the user. They are called into use by the system, not the user.
I would really appreciate any comments or suggestions on what this user
environment should look like or include.
Randy Ivanciw
Subject: Interupting a workstation session
∂27-Jun-81 1006 Steven H. Gutfreund <SHG at MIT-AI> Interupting a workstation session
Date: 26 June 1981 14:13-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
To: WORKS at MIT-AI
cc: Rivanciw.DHQ at UDEL
I would like to comment on one part of Randy Ivanciw's letter about
the need for an integrated environment for workstations. (Which I
believe much of the world is coming around to endorsing even if they
do not know how to do).
Randy gives the example where one is reading a mail inbox and gets a call
on the phone. It would be very useful to be able to drop the mail, pick
up the phone, answer the call, and then return to one's mail.
With iconographic systems (such as STAR or SMALLTALK-80) this would be
quite simple. One would use the mouse to drag the cursor away from
the current icon (be it editor window, mail inbox, virtual terminal)
and position the cursor to the telephone icon. There one would
expand the telephone icon and answer the phone. Later one could return
to the old mail inbox icon.
However, there is a problem here that several Human Factor's people
have pointed out. That is, one could easily have quite a few "pushed"
windows, each one deep in some command dialog. The Human Factor's
people have pointed out that humans have a real scarcity of short
term memory (about 4-7 chunks). Clearly, we humans are going
to have a real problem understanding what was going on in our
workstations after a couple of interruptions.
Therefore, I would like to propogate, to designers of workstations,
a user interface folk theorem that I heard recently: NEVER HAVE
MULTIPLE LEVELS OF STATE ENCODED INTO A DISPLAY.
Naturally, I am curious as to what others feel this restriction will
do to programming a user interface. I would also be interested in
collecting other folk theorems.
- Steven Gutfreund
Subject: Shades of Nicholas Negroponte
∂27-Jun-81 1022 PRSPOOL at RUTGERS Shades of Nicholas Negroponte
Date: 26 Jun 1981 1406-EDT
From: PRSPOOL at RUTGERS
To: Rivanciw.DHQ at UDEL
cc: WorkS at MIT-AI
The second part of Rivanciw's recent comments on Personal Workstations
sound very much like the DATALAND concept of Nicholas Negroponte of the
Architecture Department at MIT. Negroponte's ideas have progressed to a
somewhat more grandiose scale. He has built a special room containing a
wall-size screen and an armchair with input controls on both the arms.
His basic concept is that people often organize themselves SPATIALLY
rather than with the alphabetic keys by which ordinary random data files
are sometimes accessed. He has described the organization of a person's
desk at the office in such SPATIAL terms.
--Peter R. Spool
-------
Subject: Tools for personal workstations
∂27-Jun-81 1040 Eric Benson <BENSON at UTAH-20> Tools for personal workstations
Date: 26 Jun 1981 1103-MDT
From: Eric Benson <BENSON at UTAH-20>
To: Rivanciw.DHQ at UDEL, JWalker at BBNA
cc: WorkS at MIT-ML
One thing we should avoid in designing tools for use by non-programmers is
condescension. Elegance of design, yes, but simple-mindedness, no. There are
three aspects I see to this:
1. It should be possible in a short period of time (perhaps less than a day,
depending on the application) to learn enough about it to be productive.
2. The expert user should be able to make maximal use of the features available
without being hampered by the requirements for (1).
3. A smooth transition from (1) to (2) should be possible.
An excellent example of this is the Tops-20 command language (EXEC). I
assume most of you are familiar with it. By combining command completion
(recognition), abbreviation and menu-on-demand, the needs of expert and
novice are served equally well.
Another example is the Emacs text editor. It is used by nearly everyone
here, including administrators and secretaries. It is possible to learn
enough in an hour to make productive use of it, then acquire facility in
advanced features (editing modes, TAGS, word abbreviations, etc.) to make
it a powerful tool. In addition, since it is programmable (all key
definitions are soft), a wizard can add features for specialized
applications. (Admittedly, no one in their right mind would use TECO as a
programming language; that was a design error not likely to be repeated.)
We don't have to choose between programs that are continually asking
Do you want to pick your nose (Answer YES or NO)?
and the arcana of Unix command names. We can have the best of both worlds.
-- Eric
-------
Subject: Languages for Distributed Workstations
∂27-Jun-81 1101 Steven H. Gutfreund <SHG at MIT-AI> Languages for Distributed Workstations
Date: 26 June 1981 12:15-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
To: WORKS at MIT-AI
cc: SHG at MIT-AI
As a researcher in local-area networks I have been quite puzzled by the
rash of comments in this digest about MESA. Many people seem to feel
that having MESA will solve their programming problems.
Personally I have found MESA to be just another member of the new class of
operating system / user environment / system programming language that is
coming on the scene. I have seen nothing that especially recommends it
for local area distributed processing (either closely coupled or loosely)
and it certainly does not have the graphics or user customizability that
a language such as Smalltalk-80 has.
I believe that the choice of which language to run on a distributed
workstation is probably the most imporant one that a workstation
ARCHITECT will make. Especially since this new class of programming
languages not only define a programmer interface, but since they
are so expansive in character and tend to want to run stand-alone
and replace the exec, they also define: the user interface, the performance
of the exec, the higher level flow control protocols, the network
wide naming conventions...
The PARC group has certainly done outstanding work in many of the
areas of research in local area network languages: name servers,
flow control, metaphors for network communication, resource allocation,
distributed file systems (Woodstock), and network servers. However,
I encourage serious students of these issues to look at what other
fine researches have done:
EPL - Experimental Programming Language, Developed at the
University of Warwick, An Actor based language, currently
in use at the University of Conn. by Ed Balkovitch.
CPascal Concurrent Pascal, Per Brinch Hansen's Language for easily
building concurrent programs such as SOLO, a simple O.S.
CSP - Communicating Sequential Processes, CAR Hoare seminal work
on abstractions for distributed parallel computing.
Aug 1978, CACM
CLU - Barabara Liskov's (MIT) concurrent programming language, intro-
duces the idea of Guardians, currently in use at MIT by
Micheal Hammer's group working on the NU machine.
?? - Distributed Processes, another Brinch Hansen lanaguage for
concurrent distributed. Nov 1978 CACM
Act1 - One of the numerous Actor Languages from Carl Hewitt (MIT)
Edison Per Brinch Hansen's latest language on for multi-computer
systems.
*Mod - Modula based language being used at University of WISC in
their distributed programming project.
Actors Viewing Control Structures as Patterns of Passing Messages,
MIT AI Memo 410. Carl Hewitt's paper on Actors, Some of the
most difficult reading to be found.
DC-Pascal Distributed Concurrent Pascal, this is a language I developed,
which tries to be a fusion of the above mentioned languages.
I have not even begun to cover the full scope of literature. Clearly
this is an active area for reseach, and clearly there will be more
papers since there are plenty open areas for research.
- Steven Gutfreund
Subject: system architecture
∂27-Jun-81 1124 Rivanciw.DHQ at UDel system architecture
Date: 26 Jun 81 15:20:27-EDT (Fri)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
cc: Rivanciw.DHQ at UDel
Via: Darcom-HQ; 26 Jun 81 16:29-EDT
Peter Deutsch requested that I send along a short summation of
DARCOM's system architecture for OA (in particular hardware, software)
so here goes.
The software that DARCOM is running in its OA architecture is UNIX.
Right now we have some v6, some pwb, and some v7. We will standarize
on the latest release of UNIX from BELL. Our tools are currently all
in the public domain except for an office package that we have running
on our HQ machine called OPUS. The public domain software includes
NED, ED, MSG, MS, and (I think its public) XMSG, as well as some
home grown tools such as a suspense program (which is really a shell
routine) and an automated weekly activity report.
The hardware for our architecture is simply any machine that runs
UNIX. Currently we have 11/70s and ONYXs operational. We are
looking into the C machine from BBN. Of course we are interested in
the latest announcement on ZENIX (Unix look alike for any 16-bit
micro).
Randy
Subject: Mini/Micro Systems June 1981
∂27-Jun-81 1138 KESSLER at UTAH-20 (Robert R. Kessler) Mini/Micro Systems June 1981
Date: 26 Jun 1981 0743-MDT
From: KESSLER at UTAH-20 (Robert R. Kessler)
To: Works at MIT-AI
Two possibly useful articles:
"Xerox 'Star' shines on professionals", page 23 and
"Novell's Nexus addresses work-station market", page 99.
Bob.
-------
Subject: Re: Xerox Dolphin (alias 1100⊗?)
∂27-Jun-81 1151 Chris Ryland <RYLAND at SRI-KL> Re: Xerox Dolphin (alias 1100⊗?)
Date: 26 Jun 1981 1200-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: TEITELBAUM at RUTGERS
In-Reply-To: Your message of 25-Jun-81 1836-PDT
Yes, the Dolphin is being sold by XEROX EOS as the 1100 "Interlisp Machine."
It is about $60K, last I heard (someone at Rand or ISI correct me here.)
It is also about 3 times as slow as the Dandelion (what's inside the Star),
according to very reliable people at PARC; that is surprising, since the
Star costs little by comparison ($6K in parts costs, I've heard.)
Also, XEROX is now putting up Smalltalk on the Star, for internal use.
I have no idea, and I suppose neither does XEROX, if they'll ever release
it.
-------
∂27-Jun-81 1204 Newman.ES at PARC-MAXC Re: Xerox Dolphin (alias 1100⊗?)
Date: 26-Jun-81 12:12:38 PDT (Friday)
From: Newman.ES at PARC-MAXC
Subject: Re: Xerox Dolphin (alias 1100⊗?)
In-reply-to: TEITELBAUM's message of 25 Jun 1981 2136-EDT
To: TEITELBAUM at RUTGERS
cc: works at MIT-MC, archer at SU-SCORE
Looks like a true rumor to me. The following is excerpted from a PARC Forum
announcement sent to all users of the Xerox message system. It was an open
forum, so this is public information.
-----
The Xerox 1100 Scientific Information Processor, currently being marketed by
Xerox EOS to the research community, is a Dolphin processor running
Interlisp-D. Not only does this configuration provide comfortable
interactive performance, but the availability of Interlisp on such a low cost
machine makes economically viable the widespread use of knowledge based
technology, such as the deployment of intelligent servers in a distributed
network environment.
-----
(Xerox EOS = Xerox Electro-Optical Systems of Pasadena, Calif.)
The "Dolphin" is the same processor used in the Xerox 5700 laser printer.
This is NOT the "Dandelion" processor used in the Xerox Star.
/Ron
∂27-Jun-81 1221 mike at RAND-UNIX Re: Xerox Dolphin (alias 1100⊗?)
Date: Friday, 26 Jun 1981 11:10-PDT
To: TEITELBAUM at RUTGERS
Cc: works at MIT-MC, archer at SU-SCORE
Subject: Re: Xerox Dolphin (alias 1100⊗?)
In-reply-to: Your message of 25 Jun 1981 2136-EDT.
From: mike at RAND-UNIX
The Xerox SIP 1100 (Scientific Information Processor 1100) is really
going to be marketed by Xerox EOS (Electro Optical Systems). Here's
the deal:
It will sell for $60,000 a copy
It will have Interlisp. It will not have Mesa. It will not
have Smalltalk. (Maybe later it will, but they are not
promising it today).
It will have the 3mbit Ethernet. 10mbit later, but not this
year.
They wont sell any unless they get 'some minimum number of
orders'. The number that is most often mentioned is 40. (That
is, 40 altogether, nationwide. Not from one customer.)
The kind of maintenance available depends on where you live.
If you are not in LA or Palo Alto, then you will probably have
to do maintenance by paying time, materials and travel. The
other possibility is to stock spare parts and swap boards.
XEOS is considering, and would prefer, to have a complete
maintenance organization if there is the interest and enough
Dolphins in one place.
This deal is taking place because, among other reasons, ARPA
is looking for a way to get personal, networked Interlisp
machines to some of their researchers.
Xerox is accepting purchase orders now.
Let me know if you want a phone number for a Xerox contact. Your
local sales organization will probably not be of any help.
Michael
Subject: Personal Workstations
∂27-Jun-81 1240 Rivanciw.DHQ at UDel Personal Workstations
Date: 25 Jun 81 9:08:01-EDT (Thu)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
Via: Darcom-HQ; 25 Jun 81 9:01-EDT
In Kevin Dowling's message of 18 June he mentioned that "the
people on this list are probably not the market that Xerox is
aiming for (as opposed to the business community)". This makes
me wonder - who are the people on the personal workstation
mailing list? It might be a good idea to kind of introduce
ourselves to each other. Like the quote goes:
"Where a man stands usually depends on where he sits"
I am Randy Ivanciw, a computer specialist with the US Army
Development and Readiness Command (DARCOM). My major duties
include long range and short range planning for office automation.
I work at DARCOM headquarters (I am a civilian) as a member of
a 7 person staff dealing with the use, planning, implementation]
and other nasties of office automation.
Randy
[ If you would like to put in a brief description of who you
are and what your professional interest in this list is, we
will be happy to organize the responses for distribution in
an appropriate manner. A special mailbox has been established
to simplify the problem of collecting this material. Please
address your descriptions to WorkS-Census@MIT-AI. Thank you. ]
Subject: The Economics of Workstations
∂29-Jun-81 0747 WMACGREGOR at BBNA The Economics of Workstations
Date: 29 Jun 1981 0905-EDT
From: WMACGREGOR at BBNA
To: works at MIT-AI
cc: BTHOMAS at BBND, SCHANTZ at BBND
The commercial success of the personal workstation is largely a
matter of economics. Irrespective of the technical merits of the
various machines, they complicate installation planning by introducing
a new type of capital expenditure which typically cannot be financed
the same way as large, centralized computing centers of the past.
This may be an advantage or a disadvantage, depending on your point of
view.
On the negative side, the incremental cost of placing one new
user on a personal workstation is very large--the cost of the
workstation plus a local network interface and cabling, at least. For
centralized systems, the cost of adding one user to the community is
the price of a terminal and a terminal port (which is often dial-up,
and amortized over many users). Certainly there are many hidden costs
involved in either case, for example, the degradation of performance
of the centralized system as the user community expands; nonetheless
the capital expense of the physical equipment represents a fundamental
barrier, an "activation potential" if you will, for new users.
Are we making good use of the technology? From one point of
view, the development of personal workstations has been directed
towards increasing the computing power available to individual users
(the "KA-10 in your office" philosophy), at roughly constant or even
increasing capital cost per user. Can comparison shopping in the
small systems marketplace, a highly competitive part of the economy,
be a better idea in some cases?
In particular, I remember one reader of this list commenting to
the effect that he wasn't interested in small systems (e.g., micros
with 16-bit address spaces). I use an H89 (Z80 based system, 48K
bytes of RAM, 5" floppies) at home, and for the sake of comparison I
ran the Baskett test on this machine. I transliterated the program
into C for the C/80 compiler as directly as possible (almost token for
token), and even on the "small" system the object code is only of
modest size. The execution time was 542 seconds, as opposed to about
40 seconds for the Perq. This Z80 machine runs at a 2 MHz. clock,
which can easily be doubled to 4 MHz. reducing the run time to 270
seconds, about 6 times slower than the Perq.
I do not mean to suggest that we should all be using CP/M and
8-bit micros. But neither does it seem wise to pass over these "small
workstations" as being insufficiently powerful; they can be extremely
cost effective. The question is not whether these systems should be
used at all, but how they might be integrated into larger
environments. Suppose a user can afford to pay $3000 (about twice the
cost of a terminal) for a VT-103 (a VT-100 terminal plus LSI-11
processor). What functions can we place in this device to improve
performance? How should it be integrated into the network of personal
machines and shared hosts? Could we, for instance, support a window
package for the VT-100? (In fact, we can; examples already exist.)
From my experiences at BBN, it is clear that the economics of
personal workstations can be very complicated. Two troubling effects
that may be general phenomena are the sharing of one "personal"
machine by several people (and corresponding problems of data
security, authentication, etc., which have been pretty much ignored in
the "personal" workstation model), and the inability of low budget
projects to get into the game at all (it is difficult for people on
different projects to share the same machine, for many reasons).
I would be interested to learn how others are resolving these
issues, whether in software or by direct administrative control.
- Bill
-------
Subject: Interupting a workstation session
∂29-Jun-81 0825 Daniel L. Weinreb <dlw at MIT-AI> Interupting a workstation session
Date: 28 June 1981 22:11-EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
To: SHG at MIT-AI, WORKS at MIT-AI
I agree that it is hard for a user to keep track of a stack of
interruptions. Having to maintain a mental model of such a stack, and
having to remember what "exit this command level" will do, is a real
pain. Most interactive systems I have used have suffered from this
problem. The Lisp Machine solves the problem by having all of the
user's activities be at the same "level". There isn't any command
processor that "calls" programs which then "return" to the command
processor; you just move "sideways" from one thing to another. No
stacks are involved. (Actually there are still a few stacks in the
system, but they are being removed.) (There are some commands that mean
"switch back to the previous thing I was doing", which you sometimes
want, but nothing forces you to use these commands. (If you gives such a
"previous thing" command over and over, it switches between the same two
things, in case you were wondering.))
Not only is this easier to use, but it is more powerful. If you are
reading your mail and you are interrupted by a phone call, you can go
handle the phone call, and then put the caller on "hold" and go back to
reading your mail, and then get back to the phone call. That is, you
need not maintain a last-in first-our ordering among your actitivies.
This is one of the things I think is most valuable about the Lisp
Machine's overall user interface structure.
Subject: Re: Tools for personal workstations
∂29-Jun-81 0848 mike at RAND-UNIX Re: Tools for personal workstations
Date: Saturday, 27 Jun 1981 12:19-PDT
From: mike at RAND-UNIX
To: Eric Benson <BENSON at UTAH-20>
Cc: Rivanciw.DHQ at UDEL, JWalker at BBNA, WorkS at MIT-ML
In-reply-to: Your message of 26 Jun 1981 1103-MDT.
Eric Benson's message implicitly compares the Emacs design with UNIX.
In his words, Emacs is elegant, UNIX arcane.
And that Emacs should be a guide for future designers !
And a merry,
CONTROL META SHIFT FOO
to all of you, too.
Michael
Subject: frisbees and floppies...
∂29-Jun-81 0911 Daniel L. Weinreb <dlw at MIT-AI> frisbees and floppies...
Date: 28 June 1981 21:15-EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
To: SK at MIT-MC
cc: WORKS at MIT-AI
You asked, "The instantaneous bandwidth of such a transmission system is
very high. So who needs a Chaosnet?" This was presumably in reference
to the use of floppy disks for inter-workstation file transfer.
While the instantaneous bandwidth may be the same, the overall bandwidth,
counting the playing with the physical disks, is much lower.
Furthermore, the net is superior because (1) you can't do remote login
over floppy disks, nor asking what time it is, nor asking who is logged
in, nor anything else besides file transfer, and (2) it is very clumsy,
especially if the other machine is across the street or down the block.
Direct and easy access to a shared file server is important.
Subject: Addressing and File Accessing
∂30-Jun-81 0205 Barns at OFFICE Addressing and File Accessing
Date: 29 Jun 1981 0544-PDT
From: Barns at OFFICE
To: WorkS at MIT-ML
cc: Barns
The recent discussions of address space size, remote file access, etc.,
brought back to my mind the IBM System 38 - specifically the notion of
only one kind of addressing (48 bits in that machine) which is used
to access "main memory" or data on secondary storage - rather than
having files, there is the notion of various "access paths" possibly
existing through a great heap/swamp/"data base" of bits and bytes.
As far as I know the machines under discussion generally belong to the
Multics/Tenex/Unix school of thought that on the one hand, there is
memory, and on the other hand, there are files. All sorts of nasty things
like networks, terminals, users, etc., are mapped into one of the two
(usually files). But it seems to me more desirable (in principle at least)
to have only one kind of thing ala S/38, with various notions of access
paths, objects, classes of objects, etc.
I for one would be interested in knowing if my feeling is shared by
others, and also whether there are any plans on the part of the research
groups or other entrepreneurs to build such machine/software combinations
for those of us who would rather not program in RPG.
Bill Barns
-------
Subject: Re: el.POBox; 19 Jun 81 7:36-EDT
∂30-Jun-81 0222 Deutsch at PARC-MAXC Re: el.POBox; 19 Jun 81 7:36-EDT
Date: 29 Jun 1981 09:58 PDT
From: Deutsch at PARC-MAXC
In-reply-to: Rivanciw.DHQ's message of 25 Jun 81 8:26:40-EDT (Thu)
To: Rivanciw.DHQ at UDel
cc: JWALKER at Bbna, WorkS at Mit-Ai
The Xerox Star terminal interface is structured exactly the way
you suggest -- it gives you a "desktop" of capabilities which
(subject to the space limitations of the screen) you can "reach
for" at any time.
Subject: Multiple Levels Of State
∂30-Jun-81 0244 Rivanciw.DHQ at UDel Multiple Levels Of State
Date: 29 Jun 81 9:41:58-EDT (Mon)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
Via: Darcom-HQ; 29 Jun 81 12:27-EDT
In Steven Gutfreund's recent message on user environments he mentioned
that it would be best to "NEVER HAVE MULTIPLE LEVELS OF STATE
ENCODED INTO A DISPLAY". I am not quite sure what Steve is really
going for here - does this mean never to have more than one level
on a screen at any given time? or does this mean not to have the
system track where and what a use was doing? I am not sure.
My thought are that in my work environment I am constantly being
interupted by phone calls, urgent messages (electronics as well
as paper), and drop in visits. Often times I can not remember
where I was or what I was doing (Steve mentions this problem in
his message). It was my hopes that an office system could help
me keep track of where I was and what I was doing.
For example, right now I am composing a message to the WORKS
mailbox. Suddenly an urgent electronic message header comes up
on my screen that I must answer right now. I abort this message
(naturally saving the draft) and read the new message, check other
files (calendar, saved messages, suspenses, etc) and compose a
reply. That might take 15 minutes. In the meantime my phone
rings or I have to make a call that requires me to divert my
attention elsewhere. Then someone stops by my desk to tell me
about their weekend or talk about some configuration.
Bottom line is that I forget all about this message. I simply
did not remember where I was or what I was doing. Several days
from now I'll see a file named DRAFT-WORKS and wonder what it
is. I'll read the file into the editor and suddenly remember
what I was doing, but by then the reply may not be worthwhile.
In a very rich user system, the system would keep trach of where
I am so that when I said continue it would take me back to this
message reply and I can finish it. I feel that this tracking
would have to go at least 3 or 4 levels deep.
What are some other thoughts?
Randy Ivanciw
Subject: Re: Tools for personal workstations
∂30-Jun-81 0303 Eric Benson <BENSON at UTAH-20> Re: Tools for personal workstations
Date: 29 Jun 1981 1232-MDT
From: Eric Benson <BENSON at UTAH-20>
To: mike at RAND-UNIX
cc: Rivanciw.DHQ at UDEL, JWalker at BBNA, WorkS at MIT-ML
Mike's response (more like a Bronx cheer) forces me to clarify some of the
points I was trying to make:
First, I could not say that the design of Unix is not simple, clean and
well-integrated from top to bottom. In fact, I only objected to one thing,
certainly not a central point, which is the cryptic command names (cat, mv,
rm, sh, ls, grep). These are almost as mnemonic as PDP-10 opcode names.
(Jrst enough for some, I suppose.)
Second, Emacs is no Mies van der Rohe creation. The implementation is at
three levels, MIDAS, TECO, and Emacs keyboard input, the first two of which
are incompatible with each other and sane human beings. The single
character commands are also cryptic, but there is readily accesible online
documentation for them. Common editing commands are often used in rapid
succesion, necessitating brevity. (Although I believe I saw an editor
described in Software P & E using the Tops-20 COMND JSYS which looked
somewhat interesting for novices.) Mike (apparently) objects to the use of
extra shift keys for commands. This is required because there is no
"insert mode" in Emacs; what you see is what you get. That is what
distinguises it from every other editor I have used, and is the most
important aspect of its design. Also, by not requiring special editing
keys or other input devices such as a mouse, a good typist can remain in
registration when entering commands.
Unix was designed when CPU power, memory, address space and terminal
bandwidth were scarce resources. Its popularity (in academic circles) is
due to its accessibility, portability and malleability. I only hope
in extolling its virtues we do not overlook its shortcomings.
-- Eric
P.S. Sorry for getting a little off the topic of personal workstations per
se, but I believe this is relevant to system design.
-------
Subject: On productive text editors, suggested reading includes
∂30-Jun-81 0319 DREIFU at WHARTON-10 (Henry Dreifus) On productive text editors, suggested reading includes
Date: 29 Jun 1981 (Monday) 1448-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-AI
this month's SIGPLAN (#6) on the Text-Manipulation conference conducted
earlier this year. It goes into some detail (Yale's "Z" envr for exmpl)
on how some systems were put together, and what benefits they provide to
the work-area.
Hank
Subject: ALANTHUS System 1000 workstation
∂30-Jun-81 0330 Edward Kozel <EKozel at SRI-KL> ALANTHUS System 1000 workstation
Date: 28 Jun 1981 1236-PDT
From: Edward Kozel <EKozel at SRI-KL>
To: WorkS at MIT-AI
I have some literature on the ALANTHUS System 1000 workstation. It is
a 16-bit machine with high resolution display (15"), up to 1M of RAM,
and a set of either twin 8" floppies or a winchester drive. It is
configured in an interesting manner, with the "guts" (RAM, controller,
etc.) in a chassis sitting upright on the desk with a clipboard on
the3 side to disguise the box. This allows the entire system to be
off the floor (excepting mass store, which can be across the room).
They claim the desktop units can be lined together via a high speed
LAN, providing multi-station access to shared resources. They are
on the Federal Supply Schedule, which (I assume) lends some
respectability to the enterprise. They use both the Intel 8086
and 8088 in their various configurations.
Sounds like they are using Convergent Tech gear. Does anybody know
otherwise?
Ed Kozel
-------
Subject: Re: Xerox Dolphin (alias 1100⊗?)
∂30-Jun-81 0353 Deutsch at PARC-MAXC Re: Xerox Dolphin (alias 1100⊗?)
Date: 29 Jun 1981 09:55 PDT
From: Deutsch at PARC-MAXC
In-reply-to: TEITELBAUM's message of 25 Jun 1981 2136-EDT
To: TEITELBAUM at RUTGERS
cc: works at MIT-MC, archer at SU-SCORE
Your information is correct. The Xerox 1100 is a Dolphin with
Interlisp. Its speed is approximately 1/2 KA-10 equivalent,
assuming you buy enough memory (~ 1 MByte) so that paging doesn't
kill you. It comes with a 600 x 800 bitmap display, a 28 Mb
non-removable disk, and a mouse; I'm sure some flavor of Ethernet
will also be available. I have no information on purchase price,
delivery schedule, etc. as yet.
Subject: Xerox 1100 (Dolphin)
∂01-Jul-81 0257 DEUTSCH at PARC-MAXC Xerox 1100 (Dolphin)
Date: 30 JUN 1981 1335-PDT
From: DEUTSCH at PARC-MAXC
To: WORKS at MIT-AI
I inadvertently quoted the 1100 speed for Interlisp as 1/2 KA-10.
The correct figure is 2 KA-10. The standard configuration being sold
includes roughly 1.2 MByte memory and a network connection.
For further details (including price, availability, options, etc.),
people should contact Marcel Pahlavan in Xerox EOS at (213)351-2351.
Some people in Xerox management are understandably a little concerned
that some busybody might narrow-mindedly disapprove of the use of the
ARPANet for discussion of a commercia\ product, although I don't see
how an informed discussion of personal workstations can proceed in the
absence of quite detailed information (technical and`otherwise).
Subject: ALANTHUS System 1000 workstation
∂01-Jul-81 0321 Brian P. Lloyd <LLOYD at MIT-AI> ALANTHUS System 1000 workstation
Date: 30 June 1981 08:45-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Alanthus is indeed selling the Convergent Technologies system. There
are now three flavors of workstation: the Integrated Workstation
(IWS), the Monitor Workstation, and the Applications Workstation. The
IWS and MWS are electrically identical with the difference being that
the processor is remoted into a box like the mass storage. Only the
display and keyboard remain on the desktop. The Application
Workstation (AWS) is the "low cost" workstation and physically
resembles the IWS. The AWS is based on the 8088 (instead of the
8086), has fewer bells and whistles (no serial/parallel I/O, font
fixed in ROM, etc.), and has no Multifus expansion. The advantage of
the AWS is that it is about half the cost of the IWS and suddenly the
cost-per-workstation falls into the $5,000 range. The AWS can run all
of Convergent's software with the exception of the Font Designer.
Brian
Subject: Clarifications about interrupting workstaions
∂01-Jul-81 0334 Steven H. Gutfreund <SHG at MIT-AI> Clarifications about interrupting workstaions
Date: 30 June 1981 1p:52-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
To: WORKS at MIT-AI
cc: DLW at MIT-CI, rivenciw.dhq at UDEL
Re: Clarifying my comments on Interrupting workstation activity
I tend to aoree with Daniel Weinreb's comments about the need
to structure the user interface so that one can move gracefully
"side-ways" between windows/activities. He states that the
ability to movc "side-ways" was lone by the removal of calling
or nesting of routines.
This nesting of dialog or routines is what I am trying to point
out as a danger area for system designers. If one allows
a designer to create an arbitrary state machine by means of a
protracued dialog, then the user will be required to read the
entrails of his display to try and reconstruct the dialog that
occured earlier when he interrupted his session.
Randy Ivanciw is gorrect when he says that a system could be
built which would "refresh" the user's memory when he returns
to a window. However the problem with arbitrary state diagrams
in dialogs is that such a smart assitant would have to understand
all transitions that a user could have made. Pre-designing
such help into a dialog is a massive chore, and therefore rarely
done well or done at all.
It seems to me that if one is to follow the old maxim: WHAT YOU
SEE IS WHAT YOU GET. Then we should not have state diagrams in
dialogs which cause the user to be able to read the entrails of
his/her display to figure out what has gone on before he/she
left a window.
- Steve Gutfreund
Subject: Re: Multiple Levels Of State
∂01-Jul-81 0344 Deutsch at PARC-MAXC Re: Multiple Levels Of State
Date: 30 Jun 1981 12:52 PDT
From: Deutsch at PARC-MAXC
In-reply-to: Rivanciw.DHQ's message of 29 Jun 81 9:41:58-EDT (Mon)
To: works at Mit-Ai
Whoever mentioned the MIT Lisp machine solution hit the nail on the head: if
(1) there is no notion of "nesting" of suspensions, but rather simply a pool of
tasks in various stages of completion which the user can switch between at will,
and (2) every partially completed task is represented by a VISIBLE OBJECT on
the screen, then there is no issue about forgetting partially completed tasks,
being forced to complete them in the order they were started, etc., etc. I believe
(at least I hope) the Star works this way, since all the experimental
multi-window systems at PARC do.
Subject: Question to field: Bit Mapped displays
∂01-Jul-81 0353 DREIFU at WHARTON-10 (Henry Dreifus) Question to field: Bit Mapped displays
Date: 29 Jun 1981 (Monda{) 2210-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: WorkS at MIT-AI
o BIT Mapped displays.
Would anyone care to discuss what is a bitmap as oppsoed to
a raster-bitmap, as opposed to a whatever? I am certainly no expert
in this area, and the "Display" seems to be a key feature of most
Perscoms today.
Henry Dreifus
Subject: Addressing and File Accessing
∂01-Jul-81 0403 Vaughan Pratt <CSD.PRATT at SU-SCORE> Addressing and File Accessing
Date: 30 Jun 1981 1033-PDT
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
To: works at MIT-ML
I couldn't agree more with Bill Barns. Simplifying storage organization
is an important aspect of the more general goal of simplkfying the
user's perception of what is of necessity a very complex environment.
There is some support at Stanford for this goal; in particular we would
like to be able to offer users of SUN (Stanford University Network) a
simple coherent model of both SUN and (a rough approximation of) the
world outside SUN. Some vague thoughts along those lines appear in
<CSD.PRATT>SUNUI on Score. Brian Reid and I are mulling over such
ideas during this summer.
-------
Subject: Re: File accessing?
∂01-Jul-81 0413 DREIFU at WHARTON-10 (Henry Dreifus) Re: File accessing?
Date: 30 Jun 1981 (Tuesday) 2023-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: csd.pratt at SU-SCORE
cc: works at MIT-AI
And`what about providing parallel alternative file systems for
differing applications. Eg: Stream where Stream is good, and
chav where character is good (pipes). Make each system consistent
within itself and transparent to the end user. The system
developer can choose the file TYPEs s/he would be able to use
the most efficienly and blasto.
Hank
Subject: Re: Addressing and File Accessing
∂01-Jul-81 0428 host MIT-ML Re: Addressing and File Accessing
Date: 30 June 1981 11:46 edt
From> Frankston.SoftArts at MIT-Multics
Sender: COMSAT.SoftArts at MIT-Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: Barns at Office-2, WorkS at MIT-ML
*from: BOB (Bob Frankston)
Local: Barns at OFFICE,WorkS at MIT-ML
Poor Multics. People seem to attribute all the limitations of
its imitators to the original. One of the major advances in
Multics was its large address space and the uniform treatment
of the address space. Files are not an intrinsic part of
Multics -- only a convention for access memory through I/O
routines. There isn't even I/O -- just a set of conventions
for writing for writing an I/O interface module.
Yes, the system/38 does work out a lot of the ideas and I still
feel it is IBM's most advanced system and have suggested people
look at it as a model. But from what I hear it has not solved
its performance problems, though the model of using gobs of
computational power to provide a powerful interface is the
correct one.
The other difference is that Multics provides the full power of
its process to its users. The System/38 is packaged like a
real computer but seems to be much closer to an assembly
language/PLS interpretter running the user code. It was clever
to invent the term vertical microcode, it means that they don't
need to give you a listimg of the operating system and are free
to change the internals as long as they preserve the user
interface.
Overall I think that the System/38 is a winner and one day IBM
will tell people that it is more than a System/34 upgrade. On
the other hand, I have not used it directly and RPG III (a VHLL
production language if you want to look at it that way) is the
only language currently available. It is also a little on the
expensive side, even compared to a Star.
Subject: Errata on Barns message "Addressing and File Accessing"
∂01-Jul-81 0445 The Moderator <WorkS-REQUEST at MIT-AI>
Errata on Barns message ''Addressing and File Accessing''
Date: 1 July 1981 07:00-EDT
From: The Moderator <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
Original statement:
As far as I know the machines under discussion generally belong
to the Multics/Tenex/Unix school of thought that on the one hand,
there is memory, and on the other hand, there are files.
-- Barns at OFFICE
Comments:
Multics does not view files as something fundamentally different
from memory. Rather, it was the first system to support a uniform
single-level memory system consisting of variable size objects
(segments) from 4096 bytes to 1 megabyte in length. Files were
simulated in Multics for compatibility reasons only, and files
were constructed out of segments.
-- Paul A. Karger <PAK at MIT-MC>
An important correction for all of you who have never used Multics,
and are constantly assuming that it is like UNIX or TENEX. It is
not. Barns, for example, says that Multics/TENEX/Unix differentiate
between files and memory (and that the S/38 doesn't). Multics was
the first system to do away with the concept of file--Multics "files"
are merely part of its large virtual memory, and are accessed via
pointers. S/38 has few new ideas in this area, and a lot of crocks.
Pish tush. -- DPR at MIT-XX
You are completely wrong in classifying Multics in this group.
In Multics, there is absolutely no distinction between "memory"
and "files"; there are just segments, which live in a hierar-
chical file system and are addressed directly. The System 38
is a spiritual decendant of Multics in this regard.
Just because an idea is old-fashioned does not mean you should
identify it with Multics. For all Multics's problems and extreme
age, it is STILL ahead of its time in some ways. Sorry for the
irrelevance of this message, but I couldn't just let this go by...
-- Daniel L. Weinreb <dlw at MIT-AI>
Subject: Storage Question Restated
∂03-Jul-81 0806 Barns at OFFICE Storage Question Restated
Date: 1 Jul 1981 0628-PDT
From: Barns at OFFICE
To: WorkS at MIT-AI
cc: barns
Now that half the Multics users in the world have voiced their
displeasure, let me try to say what I was really trying to say
before, hopefully in a less offensive manner:
During the time period when Multics was born, that system
and others made varying uses of the idea of a single level
store. Naturally different people came up with different
hardware/software approaches and solved different subsets
of the universe of possible situations. Since then we have
had Tenex and Unix which have made their own contributions,
and also some steps backward because of the desire to make
something that doesn't chew up a disproportionate share of
a timesharing system's time. (Yes, many others too, but
Tenex and Unix are perhaps best known.) More recently the
S/38 has attempted to go back to some of the more general
ideas, which is noteworthy in that it is not such an enormous
processor, nor is it intended to be a timesharing system of
the flavor of Multics or Tenex or Unix. Unfortunately there
are also many unfortunate things about the 38 as now packaged
- notably the lack of programming languages that many of us
like to use, or reasonable substitutes.
Now it is my impression (unsupported by hard data) that the
38's processor is more or less in the same ballpark as (some
of) the workstation processors. This suggests that it is
not unreasonable for someone who has a mind to, to make a
programming environment on these machines, or ones like them,
which will give us a simple means of accessing data for the
purpose of local computation by the 'owner' of the workstation
and only apply restrictions on access to people elsewhere in
a network. I suggest that in the nicest form, this means that
the workstation's programs access things by an n-bit number
which is absolute for the whole workstation. This need not
mean that no other form of accessing can exist.
The question, then, is, What such things exist or are planned?
To date the responses indicate that the Lisp Machine has such
an organization and that the Perq will at some future date have
a virtual storage box to support such things at the firmware
level. Dan Lynch's message of sometime back suggests that the
STAR does its storage paging in a nasty way, not clean at all,
but details seem to be unknown outside Xerox. Anybody know
any more?
--Bill Barns
-------
Subject: Re: Addressing and File Accessing
∂03-Jul-81 0954 Chris Ryland <RYLAND at SRI-KL> Re: Addressing and File Accessing
Date: 30 Jun 1981 1131-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: Barns at OFFICE-2, WorkS at MIT-ML
In-Reply-To: Your message of 29-Jun-81 0544-PDT
Bill, the system you describe (System 38) is just a
capability-based machine, which is certainly old hat by now.
Unfortunately, this idea still seems to be barely catching on in
the "real world." Most of the seminal systems (CAL at Berkeley,
Hydra at CMU, and the Plessey System 250) were done and finished
years ago, and yet there are only a few commercial systems which
reflect this elegance of architecture (S38, Intel's 432 (in some
sense), some ICL machines). Others are working on systems which
embody these ideas (H-P's Bridge project, the S-1 project), but
most of them bastardize the design for "practicality". I surmise
that capability-based systems are finding life difficult because
no one ultimately understands how to deal with them practically
(e.g., the Hydra folks discovered quite a few problems with
accounting (who owns an object?), backup, recovery, etc., though
they also made great strides with some of the harder issues
(mostly reliability).) I think a large percentage of us would
be delighted to have a true capability-based machine if the
performance were up to what we've come to expect from current
architectures, but that doesn't seem to be around the corner (at
least in any useable way: S38 hides all its good design from the
user and masks it in the usual nonsense IBM business software.)
-------
Subject: Re: Question to field: Bit Mapped displays
∂03-Jul-81 1034 cfh at CCA-UNIX (Christopher Herot) Re: Question to field: Bit Mapped displays
Date: 3 Jul 1981 08:47:25-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: DREIFU at WHARTON-10
Cc: WorkS at MIT-AI
In response to your message of Thu Jul 2 20:26:38 1981:
Bit Map refers to the way a picture is stored, i.e. one
bit (or aggregate of bits for color) of memory for each
addressable point on the screen. As opposed to the older
"display list" technique where the picture is stored as a
list of line segments, etc.
Raster-scan refers to the method by which the picture is
refreshed on the screen, in this case, as a series of
horizontal lines, starting at the top of the screen and
moving down. As opposed to "stroke writers" which move
the beam in arbitrary directions to draw individual
graphic primitives.
The earliest displays were stroke writers. The TX-0 at MIT
moved a beam on a CRT under the direct control of the CPU.
In some sense, this was the first personal computer, as
refreshing the display didn't leave too many cycles for
anything else. Later, the direct view storage tube (DVST)
allowed the picture to be written just once instead of
being refreshed 30 or more times per second. Only problem
was that the only way to change anything on the screen was
to erase the entire screen in a blinding flash which took
.5 seconds. By the way, contrary to current publicity about
the STAR, the Advanced Remote Display Station (ARDS) storage
tube terminal was the first to offer the "mouse" as an input
device.
Stroke writers are still in common use in the CAD/CAM area.
They typically employ high-performance (expensive) analogue
circuitry to draw vectors of much higher resolution than are
currently feasible with raster displays. Resolutions of
4096x4096 are not uncommon.
The raster scanned bit map display is rapidly taking over
the display scene. It is cheaper to build circuits which
move the beam in nice sraight lines across the screen than
to build in the ability to turn corners.
To answer your question, for all intents and purposes,
raster-bitmap and bitmap mean the same thing.
-----
Subject: capability machines
∂04-Jul-81 0915 HGBaker.Symbolics at MIT-Multics capability machines
Date: 3 July 1981 14:15 edt
From: HGBaker.Symbolics at MIT-Multics
To: ryland at SRI-KL, works at MIT-AI
1. A capability is just a fancy name for a pointer in a
machine that doesn't have enough address space to begin
with.
2. The current hangup of capability machines is their
unwillingness to do garbage collection. (Tracing, etc.,
that is.)
3. Lisp was the first capability machine. It is true that
the objects are quite small in the original Lisps, but
with newer Lisps having vectors, strings, objects,
classes, flavors, and what have you, they have all the
power of Hydras, 432's, etc.
Subject: Re: Addressing and File Accessing
∂04-Jul-81 0945 Deutsch at PARC-MAXC Re: Addressing and File Accessing
Date: 3 Jul 1981 14:50 PDT
From: Deutsch at PARC-MAXC
In-reply-to: RYLAND's message of 30 Jun 1981 1131-PDT
To: WorkS at MIT-ML
I must be missing something. Barns wishes for "an n-bit
number which is absolute for the whole workstation". Isn't
a reasonable-size conventional virtual address a solution to
this problem, provided that the operating/language system
doesn't allow you to fabricate addresses? That's the only
sense in which the Lisp Machine solves the problem, and it
only does it by virtue of NOT having any local capability
for named files. The LM doesn't provide any facilities
that replace a local file system, either, e.g. there are
no tools in the system for constructing and manipulating
directories of variables. Furthermore, the LM would be
helpless without the presence somewhere in the network
of some very conventional file systems which handle messy
questions like space accounting, periodic backup, user
authentication, etc.
Of course, if you want local objects to be remotely accessible,
then you do need something much more like capabilities. Given
that mainframes (processor + memory) are so cheap these days,
compared to the cost of a reasonable-size disk, I'm more
inclined to favor putting all potentially sharable objects on
a separate server mainframe and let workstations either cache
them on their local disks or get them over the network whenever
they need to. This requires some architectural changes in the
world to make that network access comparable in speed to, say,
something between a cache miss and a bubble memory access, as
opposed to a disk access.
To the best of my knowledge, Star, like the research machines
(Dolphin and Dorado), has a conventional paged address space;
the Star OS provides for mapping full or partial files into
this space, like Tenex or Multics. The OS happens to be
optimized for mapping sequential runs of pages of a single
file into contiguous virtual pages, but that is an
optimization only.
Subject: Re: Addressing and File Accessing
∂04-Jul-81 1019 gaines at RAND-UNIX Re: Addressing and File Accessing
Date: Friday, 3 Jul 1981 11:04-PDT
From: gaines at RAND-UNIX
To: Chris Ryland <RYLAND at SRI-KL>
Cc: Barns at OFFICE-2, WorkS at MIT-ML
In-reply-to: Your message of 30 Jun 1981 1131-PDT.
It is little known, but the new versions of the Honeywell 6000
have a memory management unit, internally known as NSA (for
New System Architecture, I think), which makes the machine a
form of capabilities machine. It is elaborate and baroque,
but underneath are some very powerful ideas. The architecture
supports multiple independent domains (where a domain is a set
of addressing capabilities), such that a process can consist
of many domains.
Honeywell is slowly attempting to extend the old GCOS-III
operating system to take advantage of this, and the new
version is being called GCOS-8. In addition, Honeywell
some years acquired the XDS Sigma (formerly SDS) business,
together with a little-know, but much loved by its users,
system called CP-5. The group that moved over from Xerox
as part of this deal convinced Honeywell that the operating
system could be ported to the Honeywell processor, and have
produced an interesting system called CP-6, which takes
advantage of the domain features in some nice ways. For
example, a process can have a debugger in one domain to
debug code in other domains, putting it far ahead of
almost any other system I know (including UNIX) in this
area.
Those interested in system design and memory management
approaches ought to be aware of what is going on here. It
represents a significant extension to the thinking about
domains and capabilities. Unfortunately, there is little
in the way of reports or other decent documentation, but
perhaps some beating on Honeywell would produce something.
I'm not sure that this is the right forum for this discussion.
It would be nice if someone would start and manage a conference
dealing with operating system and system design issues. WorkS
and InfoMicro seem to have lots of people interested in these
topics, but they are really focused a bit more narrowly and
differently.
Subject: Xerox 820 Ethernet compatability
∂04-Jul-81 1047 BILLW at SRI-KL Xerox 820 Ethernet compatability
Date: 1 Jul 1981 1402-PDT
Sender: BILLW at SRI-KL
From: BILLW at SRI-KL
To: works at MIT-AI
Message-ID: <[SRI-KL] 1-Jul-81 14:02:56.BILLW>
I have here a piece of Xerox (propaganda) on the 820. I says,
And I quote:
"In addition, the 820 is an investment that will fit into
your long-range plans, since ETHERNET compatibility is
available through the 872/873 Communication Server using
Teletype communications mode on the 820"
I will not make any comments.
Bill Westfield
-----
Subject: EMACS -vs- UNIX
∂04-Jul-81 1219 mike at BRL EMACS -vs- UNIX
Date: 30 Jun 1981 at 2026-EDT
From: mike at BRL
To: WorkS at mit-ml, unix-cpm at udel
cc: Rivanciw.DHQ at udel, benson at utah-20
Folks -
"Eric Benson's message implicitly compares the Emacs
design with UNIX. In his words, Emacs is elegant, UNIX
arcane."
Both this comparison and the conclusion disturb me.
Comparing an editor (which can be thought of as having 3
levels) with an operating system (which has many levels of
complexity) is kind of off-the-wall, but lets play along...
INTENT: The intent of EMACS (as I see it) was to
provide a "what-you-see-is-what-you-get" screen editor
which behaved similarly over a wide range of terminal
keyboards (and terminals), and to permit construction
of Macros to implement higher-level features (LISP
indenting, etc). The intent of UNIX was to provide
a powerful, plesant, and consistent environment for
Computer Science types to experiment and build tools
in.
In a word, the intent of UNIX is "Software Tools",
whereas the intent of EMACS is "Software TOOL". Humm.
USER INTERFACE: Everybody will be quick to agree that
EMACS has a simple to learn user interface, at least to
gain "novice" status. The more intricate commands become
more obscure, and less mnemonic. (Everybody agrees that
Meta-Control-single←character can get obscure).
"What-you-see-is-what-you-get" is Motherhood and Apple Pie
for screen editors, and EMACS definitely succeeds here.
The UNIX user interface is designed to save typing while
remaining reasonably mnemonic. A remarkable number of
"Advanced" users can't type very well, so this is laudable.
Unfortunately, this means users take a while longer getting
used to the command abbreviations. There exist variants of
the UNIX Shell (command interpreter) which accept abbreviated
commands and do other nice, user-helpful things (although the
"standard" (dumb) shells are more common).
Initial EMACS and UNIX users face much the same problem...
LOTS OF SQUINTY LITTLE COMMANDS.
UNDERLYING STRUCTURE: As I understand it, EMACS can
be thought of as having 3 layers: The user interface/screen
control stuff, the Macro level commands, and the macro
implementation level (Typically TECO). Certainly, the top
level is easy to use. The Macro level can usually be learned
and profitably USED by ordinary mortals, but the macro
implementation level (TECO or whatnot) requires a Wizard
to get good results.
UNIX can be thought of as a number of levels, nested:
The terminal driver & line protocol (control/s/q & "cooked" editing).
The Shell (command interpreter)
Programs (System commands & User programs have identical status)
The I/O Library (Buffering & simple file mgmt)
The System-Calls (Direct requests made to the UNIX Kernel)
While each of these levels may have some overlap and
inconsistencies, the general "clean" philosophy of having
only one mechanism to accomplish one result is generally
evident, and a real pleasure! [More on this some other day]
"UNIX productivity must be thought of, not in terms of lines
of code written per unit time, but in terms of lines of code
NOT REQUIRED..."
CONCLUSIONS: I feel that EMACS is one of the better screen
editors around, mostly because of the "macro" facility which
permits powerful features to be built on top, and I feel that
UNIX is definitely the best operating system that has surfaced
to date, because of the consistent system-call interface, and
the "Software Tools" approach to commands.
HENCE, I think that all UNIXs should have an EMACS, and
everybody should run UNIX!
-Mike Muuss
Ballistic Research Laboratory
PS: There exist EMACSs small enough to fit on an 11/34, and
UNIX runs on everything these days, so this is less of
a pipe-dream than it may seem!
-------
Subject: CMU Workstation milestone
∂04-Jul-81 1250 Sam.Harbison at CMU-10A CMU Workstation milestone
Date: 1 July 1981 1509-EDT (Wednesday)
From: Sam.Harbison at CMU-10A
To: works at mit-ai
Message-Id: <01Jul81 150913 SH01@CMU-10A>
I thought people might be interested to know that CMU took
delivery of its 20'th Perq yesterday. Ten are in offices
of people working on Spice-related projects, and ten are
in public areas, also being used mostly for Spice work.
-----
Subject: Re: Ethernet capabilities of 820 and STAR
∂05-Jul-81 0920 guyton at RAND-UNIX Re: Ethernet capabilities of 820 and STAR
Date: Saturday, 4 Jul 1981 18:51-PDT
From: guyton at RAND-UNIX
To: Rivanciw.DHQ at UDEL
cc: Works at MIT-AI
In-reply-to: Your message of 1 Jul 81 11:09:18-EDT (Wed).
I worked for a couple of years for Xerox on the Star product and
after this slanderous message I will no doubt never be welcomed
back. However I can't resist trying to shed a little light on
the confusing state of the Xerox office automation product line.
The key to getting through the Xerox propaganda is to realize that
there is NOT one, but TWO office automation product lines which
have been forcefully "merged." These lines were developed by two
competing groups and don't really have much in common.
The two competing groups are now both under the common banner of
the "Office Products Divison" of Xerox, and are attempting to
cooperate. But until a year or two back . . . well, I'll be
polite and just say that they were very serious competitors.
The older group is out of Dallas, Texas. The new group is split
between Palo Alto and El Segundo (both in California). Here is a
short table summarizing what I think are their main differences:
"SDD" "OPD"
+-------------------------+-------------------------+
Location | California | Texas |
+-------------------------+-------------------------+
Programming | MESA | Assembler |
Environment | | |
+-------------------------+-------------------------+
Processor | Custom Bit-Slice | Standard u-processors |
+-------------------------+-------------------------+
Background | PARC/Research | Electronic Typewriters |
+-------------------------+-------------------------+
Product Lines | Star | 820 |
(Partial list | File Server | 850 |
due to failing | Communication Server| 860 |
memory) | Ethernet | |
| Laser printers | |
+-------------------------+-------------------------+
The two product lines evolved and were designed seperately. When
both groups were merged into the "Office Products Division" it was
decided (wisely I believe) to merge the product lines as much as
possible. So the Dallas products are all going to be on the
Ethernet, and everything will talk with everything else. It is a
worthy goal, but as you might imagine, there are a few rough spots
in trying to do it.
I hear that the Xerox sales force is claiming that they have an
integrated product line for office automation. Low cost 820's up
to the Star. Ah . . . I don't think I can agree with that. I
believe they are undermining their credability when they try to
convince people of this.
As for the confusion arising from the ignorance of the Xerox sales
force . . . they are all out of Dallas and the Star stuff is brand
new to them. When I'm not upset about the propaganda I'm actually
kinda pleased to see that they've done as good a job as they have.
Jim
P.S. Randy -- to answer your specific message, the products in
column one all have the Ethernet designed and built in from the
start. The products in column two have had the Ethernet added
with chewing gum and bailing wire (if at all).
-----
Subject: Switching tasks and context
∂05-Jul-81 0958 JWALKER at BBNA Switching tasks and context
Date: Wednesday, 1 July 1981 11:52-EDT
From: JWALKER at BBNA
To: WorkS at AI
I don't follow the relevance of all this talk about "state
diagrams" in the discussion of resuming a suspended activity.
The human side of resuming something involves answering the
question "Now, where was I?". One very effective answer to
that question is the screen display of the task as it was
when you left it. (It is perhaps not the best answer, but
the best answer involves some meta-knowledge of what you
thought you were doing and your intentions for the various
commands you had used. I am willing to assume that someone
can recognize what they were doing given the set of commands
they had issued before stopping work.)
I concur that the approach taken by the LISP machine and other
multi-window systems (that keep track of various process objects
and reinstate their displays when the objects are selected) is
correct. These systems typically provide two ways of picking up
a dropped ball -- by using a mouse to select one of the objects
whose window is currently visible on the screen, and by using
a mouse to select an object from a menu window that contains a
brief description of each of the objects. The menu gives you
complete context for "where was I?" by showing all of things you
are juggling. This is very important because the fewer details
you have to keep in your head about what you are doing, the more
head is left over for actually getting the work done...
Simply resuming a dropped activity should not be a problem
solving activity ("now, let's see, I think I had that running
as a kept fork under Hermes, which is running as a kept fork
under EMACS..."). The "multi-forking" TOPS-20 execs that exist
at several places (e.g. MIT, Stanford, Rutgers) also support
users who need to move "sideways" to do a task although TOPS-20
doesn't provide anything in the way of reinstating the display
context.
-----
Subject: Multiple Levels of State
∂05-Jul-81 1106 Mike Leavitt <LEAVITT at USC-ISI> Multiple Levels of State
Date: 1 Jul 1981 1815-PDT
Sender: LEAVITT at USC-ISI
From: Mike Leavitt <LEAVITT at USC-ISI>
To: works at AI
Message-ID: <[USC-ISI] 1-Jul-81 18:15:41.LEAVITT>
For general purposes, the LISP approach seems entirely
reasonable. For a workstation, I'm not so sure -- this
is a very special case. There are a relatively limited
number of types of things I am likely to be doing, and
each of them has its own intrinsic priority. When they
are interrupted, they carry with them an implication of
how soon they should be resumed.
For example, if I have to interrupt a phone call and put
somebody on hold, this is basically different from what
happens as I am going through my in-box and someone comes
into my office. Granted, I would like to keep track of
where I was both in the phone call, and in the in-box, but
my system should and could be smart enough to understand
the difference, and indicate that YOU HAVE SOMEONE ON HOLD,
TURKEY, before I finish the interruption and go out for a
cup of coffee. Incidentally, I have been know to leave
people on hold in just such a situation.
Also incidentally, I am not totally crazy about have
a bunch of little icons filling up my screen with
unterminated projects. My desk looks like that right
now, and that is exctly what I hope to get away from.
Mike
-----
Subject: Spatial design for a workstation
∂05-Jul-81 1206 Rivanciw.DHQ at UDel Spatial design for a workstation
Date: 1 Jul 81 10:03:14-EDT (Wed)
From: Rivanciw.DHQ at UDel
To: works at Mit-Ai
cc: Rivanciw.DHQ at UDel
Via: Darcom-HQ; 1 Jul 81 10:49-EDT
I am quite impressed with the degree to which you all responded
to my questions or thoughts on changing modes of operation in a
workstation to better reflect the way one does business.
Here is a scenario I would like to take you through. It is
about Debbie, an action officer in federal agency. Debbie
has an automated office. She has just sat down at her desk
(after getting her coffee) and is about to start her day of
work.
Debbie logs onto the system. Rather than being dropped at
operating system, she is dropped into the office automation
program (or shell). The first thing she sees is the top of
her desk on the screen.
There's an inbox, a notepad, a file cabinet, a phone, a
calendar, etc.
Debbie reaches for the inbox by either moving a cursor to
the inbox or typing "inbox". The inbox expands to fill
the entire display. In the inbox is a stack of messages
- visible on the screen. One of the messages is flashing
(or in a red envelope) indicating some level of importance.
Debbie reaches for that message first by pointing at it
with the cursor (or typing a command to read it).
The message requires a quick response. Debbie must gather
some information from several sources to answer the message.
One source of information is a phone call away. Debbie types
"desk" (or hits a function key labelled desk) and is back at
the top of her desk.
She then points to the phone and the screen fills with a
phone message pad on the left (to take notes on when a
call comes for someone else in the office) and several
phone directories stacked in the right hand corner. She
points to the phone directory labeled "DARCOM". She types
in the first couple of letters of the person's last name
(the person she is trying to reach is me - she does not
know how to spell Ivanciw - so she just types in "IVA".).
The phone directory opens to the first page with names
beginning with IVA. Debbie sees the number and dials it.
While she is talking on the phone she wants to take notes.
She gets back to the top of the desk and points to the
notepad. The notepad expands to fill the screen. She
types her notes on the notepad (which is really just an
editor).
At the conclusion of the phone call the she goes back to
the top of the desk and once again points at the inbox.
The inbox opens with the message she was last reading.
She realizes that she needs the info on the notepad to
answer the message so she types notepad - the screen
splits and the notepad with the phone notes comes on
the screen beside the urgent message.
Ah, yes, Debbie just realized that she needs some info
from the file cabinet. She types "FILE CABINET" or hits
a function key labeled "file cabinet" and a picture of
a file cabinet appears on the screen. She points to
the file drawer labeled "A-C" and it opens revealing 30
folder headers.
But wait, someone has just walked up Debbie's desk and
has asked if she had read the bulletin board this morning.
There was a notice about a presentation in the conference
room sometimes this morning. Debbie quickly hits the "desk
top" botton and points to the Bulletin Board in the corner
of her desk. The Bulletin Board expands and shows subjects
for 15 bulletins. One subject is "PRESENTATION" and Debbie
user points to it and the bulletin expands on the left side
of the screen. Sure enough, the presentation starts in 8
minutes! and Debbie wants to go to it!
Well, now she has to work quickly! Hitting the FILE function
key the screen reappears with the file drawer "A-C" open
showing the 30 folder headers. She quickly spots the file
she wants and using the cursor (or a light pen, or maybe her
finger on a touch sensitive screen) points to the folder.
The folder opens up to reveal 3 separate papers on the topic.
Once again she points to the correct paper and types "close
file". The file closes and she is back in the inbox with the
urgent message, the notepad, and the new file-paper all on
the screen.
Hell! the phone just rang and she is the only one in the
office!! She picks up the phone and finds that it is for
someone else in the office. Quickly she hits the DESK
function key to get to the top of her desk and points to
the phone. The phone expands to show a phone memo pad
and directories. She moves her cursor to the memo pad
and takes a message for her co-worker. She hangs up the
phone and types hits the CONTINUE button. (The phone
message is automatically delivered to the co-worker).
Continue puts her back into the inbox with her three
files.
She decides that she can't finish the message right now
so she hits the bye button and goes to the presentation.
Debbie knows that the next time she enters her inbox the
three files will all be there and she can dig right into
the reply to that message.
********************************
Notice a few things:
o She never had to give a command to run an editor or a
message system. She only pointed to a function and if
it used the message system it used it (INBOX) or if it
used an editor it simply used it (PHONE MEMO, NOTEPAD)
and never required Debbie to type MSG or NED or EMACS
or whatever.
o She was interrupted several times and had to move through
several systems. In all cases she never had to say
"suspend" or "save" - she just went to another function.
When she returned to the function she left it was right
where whe left it. Imagine somebody constantly clearing
off the top of your desk everytime you changed functions
- that is basically what we do in the automated office
tools of today.
The above scenario is a concept that DARCOM is considering
incorporating into its office automation environment.
Please let me know your thoughts on this concept.
Randy Ivanciw
-----
Subject: Ivanciw's ideas &c: comments
∂06-Jul-81 0329 STECKEL at HARV-10 Ivanciw's ideas &c: comments
Date: 5 Jul 1981 (Sunday) 2116-EST
From: STECKEL at HARV-10
To: WorkS at MIT-AI
As an implementor type, I have a few questions. When I work,
I have at least three stacks of things on my desk (where each
stack has sub-sub-sub-, etc. stacks):
a) what I am trying to do on a long term
b) what I started this morning because it's gotta be done today
c) the phone rang and you need it when?!?!
So... the idea of "kept context" is a nice one, but I suspect
that there could be a lot of mess. What happens in Randy's
scenario when the phone call about line 78 (+ or -) required
the use of (1) messages (2) filing cabinet? How do you "file"
where you were in a file cabinet? My file cabinets have about
3000 things in them.
I also have a quibble about the "desk" key. If the interactive
whizzes can make the super page screen work, I would much rather
never have my "desktop" hidden...
I trust my machines about as far as I can throw them when it
comes to saved contexts. Why doesn't the "phone", "pad", etc.
stay around in "icon" form? Part of the idea of piles is that
you can still see the existence of a pile, even if you're not
too sure what's in it.
Unrelated quibble concerning EMACS, &C. I am in the (lonely)
minority of those who cannot stand EMACS, and have limited
tolerance for any screen editor I have yet seen.
A) all I have experienced know far too much about what I
"want" to do (words, lines, etc. are too fully built
in) Quick, what does your screen editor call a "word"?
B) the mouse-type input ones use too many hand motions - I
touch type my TECO commands; why should I have to slow
down?
C) the control-meta-shift ones make me use many fingers at
once. I don't like that either. Also, the more obscure
the character, the less likely it will survive (1) my
memory (2) the system deciding it wants that character
This is merely to say that I think editor design is in the
dark ages, and EMACS ain't God.
Back to Ivanciw's scenario:
Does he envision a page printer, etc., for that item in the
file cabinet? My file cabinets are full of brochures from
manufacturers which arrived by U.S. Snail. Do we encode
them with a TV camera? I have had much difficulty trying to
digest any message longer than about 25 lines via any screen.
The present Workstation message blizzard gets imaged out on
a Calcomp (nee Gould) 200 dot-per-inch plotter in "micro"
form (280-character columns per page) so I can sit down and
quit craning my neck at the screen.)
Anyway, my point is: the workstation seems great if all I/O
is within the electronic environment, but falls down when
you get things like hard paper involved. I hope I provoke
a little controversy.
geoff steckel
Subject: Re: Tools for personal workstations
∂06-Jul-81 0402 Daniel L. Weinreb <dlw at MIT-AI> Re: Tools for personal workstations
Date: 5 July 1981 19:42-EDT
From: Daniel L. Weinreb <dlw at MIT-AI>
To: lwa.INP at MIT-MULTICS
cc: WORKS at MIT-AI
Actually, quite a few users of Multics Emacs (in particular)
do learn to write extensions. Multics Emacs has an extension
language that is particularly easy to learn and start using,
and it is well-documented. Secretaries do this as well as
computer programmers (secretaries are often underrated; there
is a wide range of people doing secretarial things out there,
and some of them are pretty damned smart people). You'd be
surprised.
However, there will always be a lot of users who don't want
to learn to "program". I think the key to making programming
painless is to use programming-by-example systems. Emacs
keyboard macros are a start in this direction, although they
are too simple-minded to do the job adequately at all. Dan
Halbert's Master's degree work at U. C. Berkeley is a
particularly good example of a prototype of such a system.
I hope more people work on this in the future.
Subject: Re: capability machines
∂06-Jul-81 0434 Chris Ryland <RYLAND at SRI-KL> Re: capability machines
Date: 5 Jul 1981 1619-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: HGBaker.Symbolics at MIT-MULTICS, works at MIT-AI
In-Reply-To: Your message of 3-Jul-81 1415-PDT
Sorry, Henry, but a capability is NOT just a fancy name for a
pointer in a machine that doesn't have enough address space
to begin with. I was referring to capabilities in their full
encapsulation sense, such that you can only manipulate an object
if you have the rights to do so (encoded in the capability)
and you can only do it by invoking an appropriate entry in the
capability's type module. (This is only suggestive; particular
implementations differ, of course.)
No, some capability machines do garbage collection. Hydra did.
Lisp is not a capability machine. Lisp is just a low-level
language for a symbolic-object machine, and thus is attractive
to hackers, because they can grovel with arbitrary "addresses"
when they please (CADDADR, for example.) Of course, no one in
their right mind would use Lisp that way today.
/Chris
-------
Subject: Re: Spatial design for a workstation
∂08-Jul-81 0144 Mike Leavitt <LEAVITT at USC-ISI> Re: Spatial design for a workstation
Date: 7 Jul 1981 1902-PDT
Sender: LEAVITT at USC-ISI
From: Mike Leavitt <LEAVITT at USC-ISI>
To: cfh at CCA-UNIX
Cc: Rivanciw.DHQ at UDEL, works at AI
Message-ID: <[USC-ISI] 7-Jul-81 19:02:46.LEAVITT>
In-Reply-To: Your message of 6 Jul 1981 13:06:26-EDT
If there is a real problem with people preferring to type a few
characters than to scroll a screen (or move a mouse?) then is
one solution a more sensitive touch-screen device than is now
easily available? I guess I would prefer pointing to a
particular icon to any of the above.
Mike
Subject: Contexts as Icons
∂08-Jul-81 0204 Lawrence Butcher at CMU-10A (X335LB50) Contexts as Icons
Date: 7 July 1981 2219-EDT (Tuesday)
From: Lawrence Butcher at CMU-10A (X335LB50)
To: works at mit-ai
CC: Gene Ball at CMU-10A
Message-Id: <07Jul81 221925 LB50@CMU-10A>
"I am sitting at my Personal Computer (terminal) in the middle of
some work and something different comes up. I get confused."
The solutions to this problem range from having lots of windows
on the screen to having little paper airplanes which are shot from
user to user to transmit phone numbers.
The Star lets the user name available services by pointing to Icons.
Pointing to an Icon generates new more detailed Icons, or causes some
Icon-dependent action to happen, or causes a window to appear thru which
the user can interact with the named service. The collection of Icons
and windows are the context within which a user does work.
When a person services an interrupt, he would like to bundle up his
previous context and stick it somewhere. When the interruption is taken
care of, the old context is returned to. It is not reasonable for a
user to have to smash all of his present windows up to the upper left
side of the display to make room to work on his new context. It is equally
unreasonable for a user to have massive piles of overlayed windows.
A much better solution than windows would be a formal context manager
which allows you to group Icons, windows, and related running programs
into little "context" objects. These could be manipulated just like
mail, files, and windows containing command interpreters. One could use
the Context Manager Icon to gain access to and to manipulate lists
of contexts.
In order to be useful these Contexts should be able to contain any
object namable by the user. This should include Icons, instances of
running programs, and should also include the user's organization of
these objects onto his display. A Context should also be able to
include other Contexts.
Users commonly work on a single project for longer than a single
day. To make this possible, Contexts must outlive terminal sessions.
They must be portable between communicating machines. The user should
be able to move down the hall and have his work follow him. The
Context should be available the next morning, even after orderly system
shutdown.
Does anyone have any experience with a system like this??
Subject: Multiple Levels of State
∂08-Jul-81 0219 Vaughan Pratt <CSD.PRATT at SU-SCORE> Multiple Levels of State
Date: 5 Jul 1981 1145-PDT
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
To: works at MIT-AI
5-Jul-81 11:07:14-PDT,1438;000000000001
Mail-from: ARPANET site MIT-ML rcvd at 5-Jul-81 1106-PDT
Date: 1 Jul 1981 1815-PDT
Sender: LEAVITT at USC-ISI
Also incidentally, I am not totally crazy about have
a bunch of little icons filling up my screen with
unterminated projects. My desk looks like that right
now, and that is exctly what I hope to get away from.
Mike
-----
Automation works yet another miracle. Lotsa luck.
-------
Subject: Re: Switching tasks and context
∂08-Jul-81 0232 Nowicki at PARC-MAXC Re: Switching tasks and context
Date: 6 Jul 1981 10:32 PDT
From: Nowicki at PARC-MAXC
In-reply-to: JWALKER's message of Wednesday, 1 July 1981 11:52-EDT
To: JWALKER at BBNA
cc: WorkS at AI
I can't help describing a Multi-window terminal program I wrote last year at
Stanford (with the help of Vaughan Pratt and Jeff Mogul). My reasoning was
that although "integrated systems" with menus and standard user interfaces were
desired in the long run, we needed a short-term tool to help develop such
systems. My program runs on the SUN workstation, which provides RasterOPs
on an 800x1024 bit screen at roughly the speed of 16 pixels/microsecond, and
computing power about 1/4 of a VAX-11/780.
The program has one simple function: an aribtrary number of virtual terminals
are displayed in arbirary windows on the screen. Each of these virtual terminals
may be to any machine on the local ethernet, or on the Arpanet (via a
gateway). Characters the user types get sent to the "current" host, (except for
one escape character used to enter commands), and characters sent from the
remote hosts get printed in the corresponding virtual terminal. When something
more urgent comes up, you just create another window (which can partially or
fully overlay the other windows), and when you're done you destroy that
window. At any time you may select any window to be "current", so there is no
LIFO restriction.
The important thing is that such a tool WORKS, and I find incredibly useful.
The virtual terminal uses ANSI standard escape sequences, so we can use all the
tools that have been around for a long time (like the SAIL Display Service,
Emacs under TOPS-20 or Unix, etc.) with NO modifications. We are planning to
use this to develop a more integrated system, but it is nice to have the power of
all that useful but obsolete software out there.
-- Bill
Subject: not putting phone messages into electronic mail files
∂08-Jul-81 0247 Paul A. Karger <PAK at MIT-MC> not putting phone messages into electronic mail files
Date: 7 July 1981 18:44-EDT
From: Paul A. Karger <PAK at MIT-MC>
To: WorkS at MIT-AI
cc: PAK at MIT-MC
I must disagree. Putting phone messages for people in the same office
into the computer is extremely useful. My secretary mails mine to me,
so that I can review them either from home that evening or from
another site connected to the network.
This in turn raises a question. If I have an elegant work station at
the office with graphics and icons, etc., how do I read my electronic
mail from home on a cheap, slow terminal (probably 300 baud at best)?
Do I have to learn a whole different command language? Computerese
instead of pointing devices?
Subject: Re: A Quibble or two
∂08-Jul-81 0306 Joe.Newcomer at CMU-10A Re: A Quibble or two
Date: 7 July 1981 1218-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: Frank J. Wancho's message of 6 Jul 81 09:37-EST
I see nothing unreasonable about entering something in the computer "for
someone in the same office"; I don't see that spatial proximity should
require using an alternate method of notification, assuming that the
mechanism is already satisfactory. If using little pieces of paper is
more effective than using the computer, this indicates that something
is very wrong in the design of the software. Either the software is
good enough to replace paper, which is presumably the intent, or somebody
blew the design. Thus, we have a very good way of determining if the
designers built a system tailored to human needs, or one which is simply
intended as an ego trip for the designer.
I still don't understand why people seem to think "rings" or "stacks" or
other complex connected graphs are remotely reasonable for representing
past context. The top of my desk has no little strings connecting all the
things I'm doing, and I don't miss them; if I have to deal with such a
mechanism on my computer, then somebody who wrote the software doesn't
understand how people do work. See above predicate test.
A more serious problem is, given massive amounts of state, how do you
preserve them over a system crash? In the case of distributed systems,
it is even harder, since the state may be embodied in many (potentially
unreliable) separate machines. In the best of all possible worlds, when
my personal workstation rolls in the door, I turn it on. If I turn it
off, the result of turning it back on should be to put me back in the state
I was in when I turned it off. Likewise for system crashes. If some server
somewhere crashes, this should be of no interest to me, even if I'm using
it; when it comes back, my work continues just where it left off. None of
this is easy, and some of it is probably impossible, but I think it is
important enough that we should be concerned about reliability at a level
above parity and disk scavengers.
joe
Subject: Re: not putting phone messages into electronic mail files
∂09-Jul-81 0340 JWALKER at BBNA Re: not putting phone messages into electronic mail files
Date: 8 Jul 1981 0939-EDT
Sender: JWALKER at BBNA
From: JWALKER at BBNA
To: WorkS at AI
Message-ID: <[BBNA] 8-Jul-81 09:39:40.JWALKER>
In-Reply-To: Your message of 7 July 1981 18:44-EDT
The answer to "how do I read my electronic mail from home..."?
I have heard PARC aficionados say "Well, you WON'T work at home.
You'll be so much more productive during the day that you can
leave your work behind when you walk out the door." This position
does not constitute an answer to the problem. It is imperative
that we consider all modes of work in designing the next generation
of working environments. More people will start to work at home --
surely we have all heard predictions of electronic piece work and
cottage industry. More people travelling on business will be
carrying tiny terminals with them.
The question is serious. People have to think about how to subset
both the hardware and the software so that the essential style of
the interaction can remain. Of course someone working away from
their normal desk is somewhat handicapped now, but with good
planning (taking the right papers and materials with you) you can
write more on a plane than you can at your desk in the same
elapsed time. Workers whose desks are electronic shouldn't be
prevented in principle from having analogous benefits.
Jan
Subject: Re: not putting phone messages into electronic mail files
∂09-Jul-81 0358 Deutsch at PARC-MAXC Re: not putting phone messages into electronic mail files
Date: 8 Jul 1981 09:39 PDT
From: Deutsch at PARC-MAXC
In-reply-to: PAK's message of 7 July 1981 18:44-EDT
To: Paul A. Karger <PAK at MIT-MC>
cc: WorkS at MIT-AI
I have developed, and hope to publish soon, a detailed proposal
for a protocol between bitmap workstations and mainframes. The
protocol is probably not suitable for a 300 baud connection, but
1200 might be quite reasonable. What it demands on the terminal
end is something of approximately the computing power of the
present home micros -- it needs to be able to do RasterOp, some
simple memory allocation, and sequential communications. It
needs quite a lot of memory for the bitmap(s), but memory is
getting cheaper fast. It is designed for exactly the present
kind of workstation -- bitmap display, keyboard, mouse or
similar pointing device.
Such a protocol is, of course, not sufficient to let you read
your mail elegantly at home. What it requires is a system
(hardware and software) architecture in which the mainframe
is decoupled from the display. Fortunately this is a very
reasonable architecture even for the present generation of
workstations like the Star. If the display component and the
mainframe component are located close together, the bandwidth
between them will not significantly degrade responsiveness
compared to the present more tightly integrated architecture.
Subject: speaking of touch panels...
∂09-Jul-81 0419 Hal at MIT-MC speaking of touch panels...
Date: 8 JUL 1981 0755-EDT
From: Hal at MIT-MC
To: WorkS at MIT-AI
Does anyone know of touch panel technology that is good enough so
that one could use it instead of mice? One would need to be able
to pick out a region the size of a character. I've heard rumors
of systems that allow one to resolve at less than a fingertip's
size, but have never seen one in operation. In general, what do
people think about the use of mice vs. touch panels vs. whatever?
Subject: Re: Spatial design for a workstation
∂09-Jul-81 0427 cfh at CCA-UNIX (Christopher Herot) Re: Spatial design for a workstation
Date: 8 Jul 1981 17:17:53-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: LEAVITT at USC-ISI
Cc: Rivanciw.DHQ at UDEL, works at AI
In response to your message of Tue Jul 7 22:02:18 1981:
The problem with spatial data organizations is that they are
really a class of menus, with the attendant problem that you
can not display every possible choice on the screen at once.
You can deal with this either by enlarging the data surface
(so that the user must move his window over it) or by creating
a hierarchy of spaces.
In either case an expert user will find that it takes more
time to locate a particular command than to type its name.
>From my own brief experience, I think that programmers would
find a spatial layout most useful for organizing short-lived
objects, like contexts. The feature that programmers using
our system like best was the ability to create a number of
such contexts and move among them - like having several
terminals in your office.
Subject: Context Managers
∂09-Jul-81 0446 SHG at MIT-AI Context Managers
Date: 8 JUL 1981 1339-EDT
From: SHG at MIT-AI
To: WorkS at MIT-AI
It was recently suggested (by Lawrence Butcher@cmu10-a) that
in order to manage a "desk" full of icon's what we need is a
global context/icon manager that understands how to organize
the icons on a desk. Several people have suggested that one
needs a hierachical, all-knowing, state preserving "assistant"
in order to provide uniform access, continuity across
interrupted sessions, and conformity across different users
of the same desk.
It probably is my background in workstations (implementing
Smalltalk-80, a very distributed control machine) but
I have viewed the concept of a global organizer and
continuity/conformity enforcer as a mistake.
I see workstation developers and end-users developing zoo
of different types of icons. (The reason I say zoo is that
I see each icon behaving as an anthropomorphic instance of
a real-world tool). Thus secretaries, financial analysts,
accountants, managers and stockbrokers are going to run off
and create icons that behave like rolloindexes, memo-pads,
stock tickers, file cabinets, bookshelves, steno-pads,
calculators, and waste baskets (one can even imagine someone
implementing the anthropomorphic method for hunting through
a waste basket, or even janitors who pick up the trash daily).
Users will create this zoo of icons because they are familiar
with how the real-world devices work, and because the human
race has spent many years perfecting their functions.
I do not see any reason to pre-constrain the system by having
a predefined global conformity rule about an icon's functions
and a global conformity manager who uses that rule to organize
icons.
I have no strong empirical data to back up these opinions, thus
I am quite curious as to what the WorkS community thinks about
this subject.
- Steven Gutfreund
ps: I am assuming a currently implementable workstation. I assume
that the AI community is still far away from an intelligent
assistant that can gracefully learn from a naive user how to
manipulate office equipment and then train temporary workers
on how to use someone's "desk". Since I am not up-to-date on
current research, I could certainly be wrong here.
Subject: Re: Re: Tools for personal workstations
∂09-Jul-81 0509 lwa at mit-csr at mit-multics Re: Re: Tools for personal workstations
Date: 6 Jul 1981 1050-EDT (Monday)
From: lwa at mit-csr at mit-multics
Reply-to: lwa.INP@MIT-Multics
In-reply-to: Your message of 5 July 1981 19:42-EDT
To: dlw at MIT-AI
CC: WorkS at MIT-AI
Interesting. I'd like to see more information on these "programming-by-
example" systems, as I feel that the issue of user extensibility is not
being adequately addressed in present-day designs for office automation
systems.
-Larry Allen
-------
Subject: Re: Contexts as Icons
∂09-Jul-81 0525 obrien at RAND-UNIX Re: Contexts as Icons
Date: Wednesday, 8 Jul 1981 10:34-PDT
To: Lawrence Butcher at CMU-10A (X335LB50)
Cc: works at MIT-AI, Gene Ball at CMU-10A
In-reply-to: Your message of 7 July 1981 2219-EDT (Tuesday).
<07Jul81 221925 LB50@CMU-10A>
From: obrien at RAND-UNIX
I hadn't really thought about this before, but the PLATO
computer-based education system does exactly this - it saves
state between terminal sessions. It does this only for students,
though, not for "authors" (programmers). I hadn't thought of it
before because PLATO is so strange that I really don't think of
it in terms of other computer systems.
State-saving works but can't be done blindly. It turns out
that almost all real applications ("lessons") require the author
to do his own state-saving so that the student doesn't come up
with no context, but is instead presented with a higher-level
frame that tells him where he was and presents some options.
Only blind drill-and-practice stuff can use full state-saving
at all usefully, and sometimes not even then.
Subject: Unfinished tasks, intra-office mail, and system death
∂09-Jul-81 0550 Brian P. Lloyd <LLOYD at MIT-AI> Unfinished tasks, intra-office mail, and system death
Date: 8 July 1981 07:19-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
An interesting point was made about the necessity of being able to
conveniently hand-off a task to another person. Certainly it would
be simple to just dump the task's parameters from RAM to disk and
restore them again elsewhere. While technically feasable (I have
done that on my CT system to provide task interruption capability),
this is tantamount to scooping up the mess on your desk and dumping
it on someone else's. In any case the user is probably going to
reorganize it somewhat in order to make a smooth transition. Given
this, I don't think that special capabilities need to be created
to meet this "need" (I know that those of you using large central
machines may have dificulty with my technique depending on system
architechture).
As far as intra-office mail for phone messages is concerned, I am all
for it. I dislike being told that "there has been a phone message
waiting at the operators desk for you for several hours. Why don't
you ever pick up your messages ..." especially since I have been
waiting for the call and I happened to be away from my desk for two
minutes when it came. Paper doesn't hack it here.
There are some tasks that are very painful if you lose your work
because of system death and others that are unimportant. If I
have been editing a document for hours and I lose it all because
of a system crash, I am going to be VERY annoyed. On the other
hand, if I am reading my mail and the system goes down, it will
not be very painful for me to recover from that situation. We
are going to have to do serious study as to which tasks can be
recovered easily.
Convergent has come up with what I believe is a unique method of
protecting a user from a crash during an editing session. All
user keystrokes and the original document are maintained through
an editing session. If the system dies or I wish to go back in
time in my editing session, I can do a replay and watch the system
duplicate my editing session in short order. This is an interesting
approach and I have found it to be VERY useful (like the time someone
pulled my plug when I was four hours into an editing session ... ).
Brian
Subject: Re: A Quibble or two
∂09-Jul-81 0616 Deutsch at PARC-MAXC Re: A Quibble or two
Date: 8 Jul 1981 09:44 PDT
From: Deutsch at PARC-MAXC
In-reply-to: Joe.Newcomer's message of 7 July 1981 1218-EDT (Tuesday)
To: Joe.Newcomer at CMU-10A
cc: works at mit-ai
Reliable preservation of large amounts of state in the face of
hardware failures is a topic which has been explored extensively
in the data base world. (This is a nice example to support my
contention that the present tendency of computer science to fragment
into subspecialties is to be deplored.) Generally speaking, the way
to overcome the problem is ALWAYS redundancy. The forms of redundancy
that we have explored the most are (1) thinking of the workstation as
a cache for "truth" embodied on a remote file server, or (2) logging
important state changes on a server so that the workstation state can
be reconstructed (possibly slowly) if a crash occurs. A more exotic
architecture involving multiple copies and voting is explored in a
soon-to-appear thesis by Dave Gifford (MIT). The bottom line is that
the technology is available, if manufacturers and software houses
choose to offer it.
Subject: Reliability
∂09-Jul-81 0643 Joe.Newcomer at CMU-10A Reliability
Date: 8 July 1981 1348-EDT (Wednesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: Deutsch@PARC-MAXC's message of 8 Jul 81 11:44-EST
I have contended for several years that I don't need better languages,
compilers, or editors NEARLY as much as I need a database management
system. Alas, the conventional DBMS is oriented to social security
records. I once mentioned "well, you put all that on a database"
to someone and they immediately began to explain how they had
variable-length text which a database system "couldn't handle".
Of course, a large class of uninteresting systems think in terms of
fixed-length records, but what we lose by ignoring them is that they
solve a whole lot of other problems. I once worked in the "real
world" on a banking system, and it is a good way to learn to be
paranoid about hardware and software. When you start playing with
millions of dollars of real bucks, and find that people audit their
checking accounts (and even interest on savings) to the nearest penny,
AND your company has posted a mongo amount of dollars in bond to back
up their promise that they WON'T screw up, you find that redundancy is
a way of life. DBMS systems have all had to deal with this class of
problems; the fact that their image of the data is prehistoric does
not invalidate the other solutions.
From a personal workstation viewpoint, the problem is to implement
the redundancy of state at a very low cost. If my machine crashes,
I want to boot it and get the display looking just like it did
before the crash, having lost perhaps a few small edits, or the
mail message I was composing (if it was shorter than some low
threshold) or possibly the window I just the instant before had
brought up. Doing this cheaply requires ingenuity.
joe
Subject: Re: JWalker comments on working at home, on planes, etc.
∂13-Jul-81 0920 Zellich at OFFICE-3 (Rich Zellich) Re: JWalker comments on working at home, on planes, etc.
Date: 9 Jul 1981 1036-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
To: WorkS at MIT-AI
Some of us already *do* work at home, and the receipt of stuff
that shows up in my office inbasket is a problem -- I have to
go in and get it periodically, or else have it batch-mailed to
me (the Post Awful actually does pretty good work here - I get
everything the next day).
At home I have a pretty nice workstation, but on a recent
vacation trip I took a TI745 with me, and found it not nearly
as useful as it had been when it was my *only* terminal. My
work methodology has changed so much due to the availability
of the workstation that it has become almost impossible to
get my work done with a terminal with lesser capabilities.
My electronic "filing cabinets", etc., are optimally organized
for a windowed display, and have become extremely difficult to
use from a TTY or simple scope.
It so happens that my workstation is relatively dumb (using
its internal microprocessor to handle NVT requirements only),
but the next generation should be quite intelligent - maybe
being my prime "host" itself. This all points up two problems
very neatly:
1. I need a portable workstation (or portable terminal that
can access my workstation);
2. If I use a portable terminal, then I need access to my
home workstation (the future one, that will be a
standalone system). This future system must be capable
of two-way communication; it can *not* be used strictly
to dial out to other hosts. It has to be a full host
in that it must be accessible from a remote user, and
probably from remote hosts and other workstations as
well. (gee, sounds like I just read RFC 782)
-Rich
-------
Subject: Working at home
∂13-Jul-81 0920 Joe.Newcomer at CMU-10A Working at home
Date: 9 July 1981 1447-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: JWALKER at BBNA
CC: works at mit-ai
In-Reply-To: <[BBNA] 8-Jul-81 09:39:40.JWALKER>
Huh? "I'll leave my work behind when I go out the door?"
I've never heard such bullshit. First of all, it makes
the rather bizarre assumption that I even want to come IN
the door. Actually, I would much rather work at home. This
means such serious issues as how to get reasonable communication
bandwidth between my processor and the rest of its network is a
very serious problem. And it also seems to be predicated on the
strange (and patently false, in my case) assumption that one WANTS
to leave the machine behind. I ENJOY what I'm doing, and want to
be able to do it equally well from home or "work". Thus the goal,
for example, of giving every CMU researcher a personal machine is
not really satisfactory; I need two, or at least a display with a
high-bandwidth (say, 10MHz) connection to the "real" machine.
Perhaps in that strange world where people turn their minds off
when they leave the office this is a reasonable attitude, but I've
never yet met a professional in any area who was capable of doing
this. And if you DON'T make the facilities available at home, you
are defeating the purpose of having personal workstations: to make
individuals more productive. I don't think it is the domain of
office automation designers to dictate when and where one has
automation available. Assume it needs to be available 24 hours
a day, 7 days a week, at home and "at work", THEN figure out what
the problems are.
I have this from direct experience. When I had a 1200 baud
C-100 in the office and a 1200 baud C100 at home, I could work
interchangeably in either location. When I got 9600 baud in
the office, I worked less at home. Now that I have a Perq in
the office, I can't work at home at all. This is a real drag.
I see absolutely no philosophical reason to not provide equal
computing facilities at home and at work. The only limitations
are technical (like bandwidth) and financial (most companies
can't afford two $30K workstations per user). So "office"
automation designers should go after those problems, and quit
making such totally wedged statements that seem to reflect a
basic misunderstanding of what a "personal workstation" really
should be!
joe
Subject: Office of Tomorrow, where is it?
∂13-Jul-81 0921 DREIFU at WHARTON-10 (Henry Dreifus) Office of Tomorrow, where is it?
Date: 12 Jul 1981 (Sunday) 1955-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-ML
Workstations of Tomorrow, the office of tomorrow. [Part-I]
A general feeling by most consultants, including myself, is that
the office of the future will be distributed geographically. Not
only will the 'traveling' type person be a long-distance link, but
projects will be connected by different branches - communicating
electronically.
As this effects the workstation, indeed a traveling companion
will be developed. Something akin to the Xerox "NoteTaker".
Working from home will also be a common and practical extension.
Workstation hardware will have to provide the geographic service
at some point in the not too distant future.
Somewhat more extensive from Telex/TWX 'Datagram' service, an
electronic 'Terminal in the Hotel' will at some point be provided.
I don't see any major technological problems in that. Most people
I have spoken to say they would pay $ 25.00 or even $ 50.00 more
a night to have a computer screen and a dial up modem at their
disposal.
Flying on an airplane? Why not? First Class, Business Class,
Electronics Class and Coach. Electronics class, with SONY(tm)
TypeCorders, floppy disks, and even telephone capabilities for
burst communications to one's favorite computer. It beats the
lousy movies they are showing these days.
Henry Dreifus
[Subj: Bravo/Hypertext]
∂12-Jul-81 1803 John Howard Palevich <TANG at MIT-AI>
Date: 9 July 1981 09:02-EDT
From: John Howard Palevich <TANG at MIT-AI>
To: WORKS at MIT-AI
The Bravo (& BravoX) secretary-type editors on the PARC
Altos have the "save every keystroke and the original file so
that we can always reconstruct" hack. When the system starts
to reconstruct it puts a cute "Your Editor is Experiencing
Temporary Difficulties, Please Standy By" message on the
screen, much in the style of the message TV stations read
out over the air after they drop the camera on the floor.
What ever happened to Ted(tm) Nelson's Hypertext system,
where the entire state of the document (down to the time between
keystrokes of the person editing in) was saved, and the viewer
of the document had the option of expanding the footnotes into
the referenced texts, and all that sort of thing? I think that
he was even addressing the problems of copyright & royalty
payments. . . perhaps I should mail this to human-nets, instead.
Subject: Workstation Reliability and Redundancy
∂12-Jul-81 1724 rmc at CCA-UNIX (Mark Chilenskas) Workstation Reliability and Redundancy
Date: 9 Jul 1981 14:23:18-EDT
From: rmc at CCA-UNIX (Mark Chilenskas)
To: WorkS at mit-ai
It sounds as if your problem is similiar to (and can use)
distributed database technology. The icons can be viewed as
tuples in a relation (of work to be performed, status of work,
worker, what have you). Some icons would be provided by the
system in a common format, others would be customized by each
user, probably using some menu driven options package although
for "sophisticated" users I suppose full programming might be in-
volved. The basic idea would be to have all nameable items
stored away on disk with their requisite status information.
This would preserve state info over crashes of the individual
workstations, but does not solve the problem of going to a new
workstation if your desk dies for a day or two.
In a distributed data base it has long been theorized that redun-
dant data will provide better reliability over crashes, machine
outages, etc. and provide some (possibly limited) data to the
user even if their home system is currently unavailable. Of
course this is a pain, because you have to work up protocols to
insure that the data items all stay consistent with each other
and use up lots of overhead timestamping messages or locking and
unlocking at foreign sites to update data and it is still all
very, very SLOW! The fact that Ethernet has a higher data
transmission rate than the ARPAnet and that the updates may have
simple enough formats to use coding schemes will help. But i
suspect that this will still eat an unacceptable amount of com-
pute power at task initialization and termination. Update trans-
actions are where redundancy hurts most.
Distributed databases are only partly understood. One problem is
in deciding how to split up the data. An obvious technique would
be to store templates for all common icons at each
workstation/site and let each user pick which other sites he is
likely to use occasionally. Unfortunately this will mostly mean
the user will be too brash (i don't need backup) or too cautious
(store it everywhere! Why do i run 10X slower than everyone
else?). And what do you do when the database crashes? What info
is right, and what is out of date (especially if a locking rather
than timestamp protocol is used)? This is not to mention network
partitions...
It still seems like a good application of the technology. The
redundant data goes a long way toward assuring you the type of
reliability you want. Using a common database would allow one
mechanism for transfering tasks/icons from one desk to another.
The networks will be reasonably fast. Workstations are getting
more compute power. And slowly we begin to understand some of
the design and recovery problems. There is some NICE research to
be done here...
R Mark Chilenskas
Subject: Automated desk
∂12-Jul-81 1803 wilson at CCA-UNIX (Gerald Wilson) Automated desk
Date: 9 Jul 1981 12:38:27-EDT
From: wilson at CCA-UNIX (Gerald Wilson)
To: csvax.works at Berkeley
The problem of keeping track of what quickly becomes a
multidimensional space is one we faced in the extensions of
Negroponte's work in our SDMS and VIEW systems. For SDMS we
approached it by providing two kinds of "world maps". The first
is simply a synopsis of the contents of the current work space.
Thus if you are doing several related things in this single space
(eg. building different portions of a large program), you can
always find from the world view (shown on a separate screen at
all times) where the other portions reside. The second type of
world map is a side view of all of the work spaces arranged into
a tree ( or network ). This shows a box with a label for each
work space, lines showing the connections between work spaces,
and a highlight for the work space where you currently reside.
The user can switch between world maps at the push of a function
button.
This is only a partial solution to the problem, as it does not
capture any of the real semantics of the situation. For example
you do not know how you got to the current work space, or any of
the contextual information associated with the current instance
of the work space. These are issues that we are currently
addressing in VIEW, but I have no fabulous insights to report
yet.
Subject: Re: Context Managers
∂12-Jul-81 1803 Joe.Newcomer at CMU-10A Re: Context Managers
Date: 9 July 1981 1501-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: SHG at MIT-AI
CC: works at mit-ai
In-Reply-To: SHG@MIT-AI's message of 8 Jul 81 12:39-EST
I guess I never thought of the icons as being pictures or
illustrations, but just names of windows (perhaps visible
corners of windows). Thus having a global manager in a
workstation that keeps track of all the windows seems
natural. What is your reaction to this simpler model?
joe
Subject: Icons
∂12-Jul-81 1804 Brian P. Lloyd <LLOYD at MIT-AI> Icons
Date: 9 July 1981 08:31-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Currently we catagorize workstation functions on the basis of
the existing tools we now use. Is it not possible for us to
define a new set of functions that encompasses the current
range of tools/procedures, but is much smaller? Given this,
we will have to develop a new set of icons to define the new
functions. If indeed we must define new icons, don't we lose
the existing mental correlation between picture and function?
Perhaps we should look at the whole problem from another angle.
Let us assume that the "intelligent desk" leads us in the
direction of modified worker activity. I think we should do
another system analysis and see if we can come up with a new
view of the problem: one that has an elegant [simple] solution.
Brian
Subject: Re: Reliability
∂12-Jul-81 1724 Joe.Newcomer at CMU-10A Re: Reliability
Date: 9 July 1981 1831-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: kolling at PARC-MAXC, works at mit-ai
In-Reply-To: kolling@PARC-MAXC's message of 9 Jul 81 16:21-EST
Assume the following:
A series of transactions is required to generate a consistent
database.
The cost of repeating a transaction is outrageously high.
The cost of restarting a series is even higher.
The cost of saving state at the client so that the series may
be continued is negligible.
What is the cost of the mechanism that guarantees that enough
state is preserved at the server to continue the series of
transactions given that either the server or the client may
crash?
Assume that the client, when resuming the series, may elect
to "continue" or "abort". Assume that "abort" is a truly
rare occurrence.
This is my image of the requirements of, say, a crashproof
editor that will lose no more than one keystroke if either the
client or server crashes. Note that although the "database"
(file being edited) is in an inconsistent state (relative to the
desired state), the user wishes to resume editing at the nth or
n-1st keystroke. Thus, viewing the user as the "client" and the
editor as the "server", the cost to the user of remembering which
keystroke came last or will come next is negligible. As we move
further back in time, the cost of restarting the series becomes
higher and higher. Assume for values of time > 10 keystrokes
the cost is nearly infinite. As far as I can tell, transactions
do not allow state to be SUSPENDED; they only guarantee that
under one definition of consistency, the state will always be
consistent. For a workstation, the two states in question are
the state of the workstation and the state of the work. Any
time the workstation state is consistent, the state may be
saved (the transaction completed), but this has nothing to
do with the state of the work. I think we are a long way
from being able to deal with the latter, since I think it
is perfectly reasonable to shut down the system or take a
crash when the "work" is inconsistent, as long as we can
return to the same state of inconsistency upon return and
allow the work to proceed.
joe
Subject: Touchpanels
∂14-Jul-81 0934 Steve Saunders <SAUNDERS at USC-ISIB> Touchpanels
Date: 13 Jul 1981 0939-PDT
From: Steve Saunders <SAUNDERS at USC-ISIB>
To: WorkS at MIT-AI
Why do all the answers in the digested replies on touchpanels share
these glaring misconceptions?
- that a touchpanel must be mounted in front of the display;
- that a touchpanel's resolution is limited to fingertip size.
1. Any of several touchpanel technologies, including the Elographics
and Sierracin commercial units, is entirely suitable for use away
from the display surface -- say, just where you would put a
"tablet" (pen-on-a-wire type), but without ever having to find &
pick up a pen or even find the mouse where you left it. The desk
area used need not be larger than a mouse-field.
2. This same touchpanel technology, at least, offers resolution that
is much much finer than the size of the touching fingertip -- I
have personally built and used some, and with cursor feedback I
can select individual pixel positions *within* the (projected)
area of my contact "fingerprint". This is done simply and
naturally (noone has to be coached) by rolling the fingertip.
The resistive material reads out the centroid (in some sense)
of the contact patch, allowing very sensitive control for fine
positioning, as well as instantaneous pointing without having
to find the pointer (pen or mouse) first.
*Of course* there is a tracking cursor on the display, just like a
mouse/tablet. To assume absence of this well-understood software
device gives extremely unfair comparisons.
Now that we all have that straight, how about some reconsidered
answers? Preferably this time from users of real touchpanels,
not those low-resolution or screen-mounted special-purpose
devices that were blasted (rightly) in the recent batch of
replies.
Steve
Subject: Re: Touchpanels
∂15-Jul-81 0429 JWALKER at BBNA Re: Touchpanels
Date: 14 Jul 1981 0926-EDT
Sender: JWALKER at BBNA
From: JWALKER at BBNA
To: SAUNDERS at USC-ISIB
Cc: WorkS at AI
Message-ID: <[BBNA]14-Jul-81 09:26:52.JWALKER>
In-Reply-To: Your message of 13 Jul 1981 0939-PDT
You might have noticed that some of the touch panel notes pointed
out the semantic poverty of a touch when compared to the multiple
selection buttons on a mouse. That difference holds wherever the
touch panel is mounted. It means that touch panel driven systems
have to use more menus than are needed with a mouse driven
interface.
Jan
∂15-Jul-81 0444 Steve Saunders <SAUNDERS at USC-ISIB> Touchpanel prejudice
Date: 14 Jul 1981 0839-PDT
From: Steve Saunders <SAUNDERS at USC-ISIB>
Subject: Touchpanel prejudice
To: JWALKER at BBNA
cc: Saunders at USC-ISIB, WorkS at MIT-AI
Again, random assumptions are being made. Who says you can't
mount buttons where they can be used easily with a touchpanel?
Specifically, you can take advantage of the normal use --
pointing with one hand while the other remains in "home position"
at the keyboard -- to provide either mouse or touchpanel with
lots of "buttons" (just 'cause they have letters printed on top
doesn't mean they aren't buttons!). Of course, the kinesthetics
aren't exactly alike; but the assertion implied by JWalker that
mouse is necessarily better on this ground is pure assumption.
If there's evidence, tell us about it!
I didn't say there was no DIFFERENCE, just that the touchpanel's
inferiority as being asserted on unfair (scientifically careless)
grounds, that touchpanels were being castigated for faults they
don't in fact have. They are indeed different, and the good and
bad points of that difference need to be carefully explored
without the interference of preconceived conclusions.
Steve
-------
∂15-Jul-81 0458 Joe.Newcomer at CMU-10A Re: Touchpanels
Date: 14 July 1981 1253-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: Steve Saunders <SAUNDERS at USC-ISIB>
Subject: Re: Touchpanels
CC: works at mit-ai
In-Reply-To: Steve Saunders's message of 13 Jul 81 11:39-EST
Steve,
I was assuming by touchpanels that people mean those transparent
devices, or LED-matrix arrays, that get mounted on terminal
screens. I therefore don't see any distinction between the Bit
Pad One with a piece of hardware for the cursor and the Three
Rivers touch-tablet which requires only my fingertip (except I
don't have four buttons on the touch-tablet). The fine point
that touch tablets need not be mounted on the screen did not
escape me...in fact, I even cite the 3RCC touch tablet in an
earlier note.
joe
∂15-Jul-81 0515 Steve Saunders <SAUNDERS at USC-ISIB> Touchpanels vs Tablets
Date: 14 Jul 1981 1014-PDT
From: Steve Saunders <SAUNDERS at USC-ISIB>
Subject: Touchpanels vs Tablets
To: Joe.Newcomer at CMU-10A
cc: WorkS at MIT-AI
In-Reply-To: Your message of 14-Jul-81 0953-PDT
Joe,
There is one real distinction between BitPad et al. and
sensitive-surface touchpanels, and that is the need or absence of
a gadget (pen, e.g.) that one must find and pick up (or take a
hand position on) before pointing/drawing. Is it your experience
that this is not important? I get *terribly* annoyed by the pen
on our Perq (which came with a Summagraphics tablet, not the
transparent touchpanel -- I don't know why). I think that a pen
on a cord is much worse than a mouse; what I don't know is whether
finding a mouse every time is worth having those buttons there
rather than (say) near the left hand. Have you experimented
with fully-worked-out setups that use each of the competing
technologies to its own best advantage? I really would like
to hear some information on this.
Steve
∂15-Jul-81 0533 Joe.Newcomer at CMU-10A Re: Collected commentary on touchpanels
Date: 14 July 1981 1235-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
Subject: Re: Collected commentary on touchpanels
In-Reply-To: "The Moderator"'s message of 13 Jul 81 07:30-EST
What's wrong with light pens? The same thing that is wrong
with the standard pen that comes with the Summagraphics Bit Pad
One: you've got to pick the damn thing up! I went nearly crazy
trying to use an editor for two weeks with my Bit Pad, because
the editor ONLY accepted cursor motion thru the tablet and the
ONLY device I had for pointing was the pen! One of the worst-
designed systems I ever used. After two weeks, the 4-button
mouse came in, and most of the headaches went away, but I still
had to keep taking my hands off the keyboard for the smallest
cursor motions. Now we have an EMACS like editor that accepts
cursor movement and positioning commands from the keyboard or
tablet, and it is really nice; small relative motions can be
done quickly from the keyboard and large dragging motions can
be done with the tablet; I find the system quite friendly.
(As an aside, pens seem to be predicated on the idea that holding
a writing implement is a "natural" action and comfortable. I've
never found holding a pen comfortable, and have always preferred
to type rather than write. I write almost nothing; if it is
worth commiting to an medium outside my brain, I type it into
the computer!)
joe
∂15-Jul-81 0551 Marshall Presser <MPresser at MIT-Multics> touch panels
Date: 14 July 1981 1331-edt
From: Marshall Presser <MPresser at MIT-Multics>
Subject: touch panels
To: WorkS @ MIT-AI
The touch panels I have seen had very fine precision, but very
high variability. As a reult, the software running the terminal
had to know what was being displayed where, so as to interpret
seemingly misplaced results. We tried cross wires held together
by rubber bands on the first model, but this gave us only the
roughly 20 by 20 points on a standard sized monitor. It is
unclear whether many people can or care to manipulate in a n
area smaller than a fingertip.
Others tried special resistive and capacitance sensitive
material, but this proved too variable. They, whoever they
are, tried invisable conductors inside channels on a plastic
overlay on the monitor, but this technology proved expensive
and the stuff wore down after a while.
What did prove successful was a two monitor system, one for
display purposes, and another as the "input" device. There
was of course, the problem that the programmers could not
eat peanut butter and jelly sandwiches while working late,
for it marred the surface badly. An image of a keyboard was
generated, but the touch was so awful, that a small keyboard
of the regular variety was hung on when large amounts of text
input were required. One application had people selecting
theater tickets by push down on the monitor over a picture
of seating plan of the theater or stadium. The main appli-
cations for such a terminal were commerical, for highly
reprogrammable banking terminals, and for computer access
to naive users about community information. In the second
case, they were to be used at public libraries, community
centers, etc.
∂15-Jul-81 0607 Joe.Newcomer at CMU-10A Re: joysticks
Date: 14 July 1981 1249-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: Gary Feldman at CMU-10A
Subject: Re: joysticks
CC: works at mit-ai
In-Reply-To: <13Jul81 205424 GF20@CMU-10A>
The reason joysticks are losers deals with the interaction
between the hand motion and the screen cursor motion. In
fact, it takes a lot of skill to convert a desired motion
on the screen to an appropriate nudge of the joystick. Thus,
joysticks usually result in a lot of "hunting" as the cursor
constantly overshoots the target and the user applies smaller
and smaller corrections to get it to land on the desired point
on the screen. See Stu Card's thesis; I know he presented the
reasons at his oral (I was there) and assume they are also in
his thesis.
I have no experience with tracking balls, and am currently
reluctant to offer opinions on them since I THINK I know a
very, very cute way to implement one...and I won't say more
until I've sold the idea.
joe
Subject: Picture vs. Window names
∂15-Jul-81 0633 wilson at CCA-UNIX (Gerald Wilson) Picture vs. Window names
Date: 13 Jul 1981 13:50:10-EDT
From: wilson at CCA-UNIX (Gerald Wilson)
To: works at MIT-AI
I think that the importance of worrying about the content of the
windows is closely tied to the nature of the working environment.
If the user is working with a relatively small number of windows
all of which have a fairly short half-life (probably no more than
a day), then having a nice window manager which just keeps track
by name is probably adequate, and certainly much better than
typical current facilities. I equate this solution to the ability
to declare multiple full-screen windows in EMACS, and then ask
about what windows you have created. This works nicely for me as
long as I chose good names for the windows, and I don't 'drift' on
to new things without closing out old windows.
The problem that is of primary concern to me is the environment
where a user has lots (probably hundreds over the course of a
year) of windows, many of which have long lives (> month), and
which are in various states of activity at any given moment.
When I handle this manually I often end up with a hierarchy of
storage and state preserving methods, with the "manager" being
a combination of paper and electronic messages and a mental
index. I find all the same problems that have been discussed
or alluded to in "works" messages:
* Windows change in priority and/or importance based on both
my own actions and actions of others. The biggest problem
seems to be that the actions of others can cause me to make
dramatic changes in my window organization, at least for a
short time.
* I can handle a handful of windows with little problem for a
moderate time. When the number grows I begin to lose track
of some. When the time period of a low priority window's
life is long, I also begin to lose track of it. This
corresponds to the usual observations about human memory.
* Almost invariably there are multiple relationships between
windows, and thus multiple organizations of the windows. A
single window name rarely means anything to more than one
of these views of my world. The key retrieval method is my
mental association between the window name and the semantic
aspects of the window that are of interest under given
circumstances.
* The window relationships depend upon not only the window
semantics, but also project priorities, personal preferences,
interests of the moment, machine availability, dependencies
upon co-workers, etc. Much of this meta-information about
the window organization is important to keep available, and
is used in developing priorities and schedules.
* When new windows are created I must thread them into the
existing structures, and also determine if any new structures
are required. The deletion of old windows may affect windows
not directly linked to the deleted window, as the reason for
the deletion may have implications for other windows not
otherwise related.
My conclusion is that if we are to use computers to maintain much
of our current paper files, we must provide windowing facilities
that are more versatile, more semantically oriented, and more
easily interconnected than the window naming and other similar
approaches would allow. I think that the use pictures, color,
shape, abstractions, sound, etc. are essential to this process.
They sure seem to help in manual systems, and I have not found
effective substitutes for many of them in my own limited work.
When talking with graphics people, they always use "icon" to mean
the 'total symbol', not just as the name of a region of the screen.
Although this does not imply that icon refers to any semantics, I
guess I have felt that this is a natural extension of the grahics
term.
[Subj: more on icons]
∂15-Jul-81 0700 ihnss!mhtsa!harpo!chico!esquire!nrh at Berkeley
Date: 13 Jul 1981 20:54:16-PDT
From: ihnss!mhtsa!harpo!chico!esquire!nrh at Berkeley
To: WorkS at MIT-AI
Phooey! This "endless hierarchy" of deletes is just plain silly!
Given delete and EXPUNGE, what if someone wants a file that has
been EXPUNGED? Should there be a little "Hardy Boys" icon which
given the burned junk from an "expunged wastebasket" icon could
re-construct (perhaps only in part) what was on the burnt paper
(the expunged file)?
And how about a little "paper shredder" icon so you could prevent
the retrieval of an EXPUNGED file? And if you didn't want to
trust your users to do that, you could always have a "bogus paper
shredder" icon which doesn't really shred things, but merely drops
them in the wastebasket.
On the other hand, with regular backups, and an "archives" icon,
perhaps you could simply trust your users most of the time, and
recover from backup when that failed (perhaps a "god from the
machine" icon could be shown disgorging the "lost" files).
Subject: Re: Unfinished tasks, intra-office mail, and system death
∂15-Jul-81 0714 Ted Markowitz <TJM at MIT-XX> Re: Unfinished tasks, intra-office mail, and system death
Date: 14 Jul 1981 1700-EDT
From: Ted Markowitz <TJM at MIT-XX>
To: LLOYD at MIT-AI, WORKS at MIT-AI
In-Reply-To: Your message of 8-Jul-81 0719-EDT
Perhaps with the price of harware dropping at the rate it has
been, the TANDEM approach (duplicate processors, disk subsystems
which "mirror" the data, etc.) might be a reasonable method to
accomplish state saving. I don't see this right away, but it
does provide another avenue to make sure that your desk doesn't
wind up 'disappearing' because of an electrical spike or a loose
cable.
--ted
Subject: Reliablity
∂15-Jul-81 0729 BHYDE at BBNG Reliablity
Date: 13 Jul 1981 1120-EDT
From: BHYDE at BBNG
Sender: BHYDE at BBNG
To: Works at MIT-AI
Message-ID: <[BBNG]13-Jul-81 11:20:13.BHYDE>
Folks,
There are very few new ideas that computing has had to date.
The keystroke backup file is only the editor instantiation of
a very old idea; double entry bookkeeping. An idea that some
have blamed all capitalism on. As each transaction occurs in
any organization it is recorded in two places, the journal and
the account book that it is related to. These two sets of books
are stored in separate places if at all possible and either set
can be used to reconstruct the other. This is a very important
reliability mechanism since it is the only one that is acceptable
to accounting organizations. As the only "certified" mechanism
it is the only primitive available for most commercial systems
to achieve reliability. Thus the terms audit trail or journaling
are very popular in commercial product offerings.
Ben Hyde.
Subject: SUN Workstation
∂15-Jul-81 0747 Andy Bechtolsheim <AVB at SU-AI> SUN Workstation
Date: 13 Jul 1981 1738-PDT
From: Andy Bechtolsheim <AVB at SU-AI>
To: WorkS at MIT-AI
From: Minsky at MIT-AI
Subject: SUN query
Gee, where does one get a SUN and how much does it cost?
--------------------------------------------------------
SUN Workstation Synopsis:
Processor: 8 MHz 68000, executing without wait states.
Memory Management: two-level, multi-process, segment-page memory map.
Main Memory: 384 kBytes (128 kBytes reserved for frame buffer).
Graphics: 1024 by 800 pixel display, high-speed "RasterOP".
Network: 3 MBit/sec "experimental" Ethernet.
Pointing Device: optical "mouse".
Backplane Bus: Intel Multibus.
Operating System: Microsoft Xenix.
OEM-Price: under $10,000.
We are currently evaluating manufacturing arrangements for
SUN workstations. Stanford University plans to get 25 SUN
workstations by the end of this year. If you are interested
in participating in this pilot production run, please contact
AVB @ SAIL.
Subject: Collected Responses on Touchpanels II
∂16-Jul-81 0524 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected Responses on Touchpanels II
Date: 16 July 1981 0700-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
Here is the second set of collected responses on touchpanels
and other cursor moving devices. They are being distributed
in this form rather than as individual messages, because this
is the only way that we can manage to promptly distribute the
incoming volume of mail to this list.
Enjoy,
RDD
------------------------------
Date: 15 July 1981 08:54-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: BitPad Experiences
To: WORKS at MIT-AI
We at DEC did not have mouse hardware on hand. What we did
have was a SummaGraphics BitPad with crosshair cursor that has
4 buttons (bugs in the PARC terminology) on top. It was fairly
easy to write software so that we could have a relative postion
mouse instead of an absolute location cursor. We even hyped
up the sensitivity of the mouse so that simple (wrist only)
movements could carry one across the entire screen. One can
even lift up the cursor and replace it like a real mouse.
Opinions:
Given the way the smalltalk window editors work, I can keep
almost all of my activity off the keyboard. Indeed I think
if I was given a chord keyboard in my other hand (5 buttons
could give me 120 different keys) then I could completely
get rid of that anachronism of the industrial age: the 4
row QWERTY keyboard.
- Steven Gutfreund
------------------------------
Date: 15 Jul 1981 1032-PDT
From: Michael Dolbec <CSD.DOLBEC at SU-SCORE>
Subject: Re: Touchpanels vs Tablets
To: SAUNDERS at USC-ISIB, Joe.Newcomer at CMU-10A
cc: WorkS at MIT-AI, CSD.DOLBEC at SU-SCORE
In-Reply-To: Your message of 14-Jul-81 1014-PDT
The Alto set up has a mouse with 3 buttons ("bugs") for the
right hand, and a 5 key device for the left to play with.
There are text editors in Smalltalk that allow the mouse to
be used primarily as a pointing device while the key-set is
used to select actions and modes. So you see, devices exist
to keep the other hand busy also. I believe that Englebart
at SRI used a key set too. --Mike
------------------------------
Date: 15 Jul 1981 10:18:56-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: Saunders at isib
Subject: touch sensitive digitizers
Cc: WorkS at mit-ai
While using a touch sensitive digitizer (tsd) on a table
top wins in that you don't need to find a special stylus
with its clumsy wire, it suffers from the fact that other
objects, such as the palm of your hand, can set it off as
well. I heard that Elographics has a tablet that works
only with sharp objects. Has anyone had any experience
with it?
I am very wary of any comparisons made from theoretical
perspectives. In the long run, the most successful
input technique, whether tsd, tablet, or mouse, will
depend on which one "feels good" and works reliably.
As you pointed out, this depends a lot on how the
software is implemented.
------------------------------
Date: 15 Jul 1981 0843-EDT
From: WMACGREGOR at BBNA
Subject: Pointing Devices
To: works at MIT-AI
I agree with Steve Saunders position that touch panels
may not be as inferior as commonly assumed. Certainly mice
have their advantages, but they have problems too. Because
the machine cannot determine the absolute position of a
mouse, it is awkward, at best, to use as a digitizing device.
Tablets are much better, since a stylus can be traced over a
graph or map placed on the tablet.
Even though mice do not require dedicated desk space in
theory, I have seen many users place a plastic sheet on the
desk (some kind of heavy vinyl with a tacky-feeling surface)
to give the mouse good traction. If you're going this far,
there is little advantage over a BitPad-type tablet.
Joysticks seem to be dismissed out of hand, and on the
whole I agree. However, one variant of the joystick, the
'force stick', I suspect is comparable to a touch panel or
mouse if properly engineered. (A force stick remains in
one place, and produces an output proportional to the forces
exerted on it in the X and Y directions; they are usually
elastically mounted, so that they bend slightly, maybe 1/8"
maximum, when force is applied).
- Bill
------------------------------
Date: 15 Jul 1981 1304-PDT
From: Park at SRI-AI
Subject: PWS cursor control
To: works at MIT-AI
Suggestions for New Kinds of Cursor Controllers
by
Bill Park
SRI International
One of the recent developments in robotics is a thin, flat sensor
that can measure force distributions normal to its surface as well
as shear forces. It might make a very convenient, rugged, reliable
fingertip cursor control.
These devices can be fabricated as array sensors with resolutions
on the order of a millimeter. They are intended for use as tactile
sensors to be installed as "fingertips" on robot hands, e.g., to
adjust gripping forces to prevent slippage. People at M.I.T.'s
Artificial Intelligence Laboratory, among others, are building
and experimenting with them.
They are typically made by embedding layers of parallel flexible
metal conductors in a matrix of silicon rubber that has been doped
with granules of an electrically conductive material such as carbon
or silver. Local conductance of the material is then a function of
local stress. A microprocessor measures the resistance between
selected pairs of conductors to determine the stress distributions
throughout the material.
You could mount one of these sensors flush with the top surface
of the keyboard housing, and use it somewhat like a trackball as
follows:
(1) Whenever the operator touched it with a finger, the micro-
computer would determine the centroid of the distribution of
pressure exerted. (Using the centroid might overcome the
objection to high resolution in a touch-sensitive device to
be operated by a "fat finger.") The location of this centroid
would determine a corresponding coarse location on the screen
at which a cursor would appear. Rolling the finger slightly
or sliding it over the surface would allow fine adjustment of
the cursor position. This is a small-muscle task which I
believe would be easy to learn and to perform rapidly.
(2) Pressing harder on the surface could signal a special action
to perform at that point, such as placing a marker on the
screen or changing the mode of operation. Using modes (1)
and (2) alternatively, one could quickly place a sequence of
markers around a block of text or a polygonal region of an
image.
(3) Pushing the finger along the surface (producing a shear
stress signal) could then indicate a corresponding vector
in the plane of the screen. This could be used, for example,
to control cursor velocity or to move a previously delineated
region of the image around on the screen.
I think it might be most convenient to mount such a control on
the keyboard within easy reach of either thumb, such as on the
front edge of the housing below the space bar. One would then
not have to move one's hands at all to point at things on the
screen.
A much cruder device is available commercially. It is a linear
array of parallel electrical conductors. Stroking it produces a
bipolar analog signal. It is marketed as, e.g., a more rugged,
completely sealed replacement for a knob on a piece of military
electronic gear. Two of these could be mounted at right angles
to one another within reach of a thumb to control incremental
horizontal and vertical cursor motion.
Another possibility for minimizing hand motion would be to
incorporate a miniature 2- or 3-degree-of-freedom joystick
into the keyboard, in the form of one more, special, key.
Or even several such "joykeys."
------------------------------
Date: Thursday, 16 July 1981 03:28-EDT
From: Jonathan Alan Solomon <JSOL at RUTGERS>
To: Steve Saunders <SAUNDERS at USC-ISIB>
Cc: JSol at RUTGERS, JWALKER at BBNA, WorkS at MIT-AI
Subject: Touchpanel prejudice
Touch Panels! Touch Panels! Indeed. Give me the greatest touch
panel known to man, the Terminal Keyboard. Some of them even
come detachable.
Seriously, since the primary appeal for workstations will be to
users who already have some aptitude on computers, there should
probably be some correlation between touch panels and terminals.
(here I envision my briefcase-thin terminal with the touch panel
screen which doubles as a keyboard).
Jsol
------------------------------
End of Collected Responses on Touchpanels II
********************************************
Subject: Re: Picture vs. Window names
∂16-Jul-81 0604 Chris Ryland <RYLAND at SRI-KL> Re: Picture vs. Window names
Date: 15 Jul 1981 0911-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: works at MIT-AI
In-Reply-To: Your message of 13-Jul-81 1050-PDT
I recommend heartily that everyone stop wondering about window/session
managers until they read the four PIE papers now available from PARC,
by Ira Goldstein and Danny Bobrow. PIE provides most of the mechanics
for exactly the kinds of things people are meandering verbally around.
I'm referring to report CSL-81-3 from Xerox PARC. Also related, though
possibly not available yet, is CSL-81-4, ``PIE: An Experimental
Personal Information Environment.''
Subject: pukcba ekortsyek
∂16-Jul-81 0620 Frankston.SoftArts at MIT-Multics pukcba ekortsyek
Date: 15 July 1981 20:40 edt
From: Frankston.SoftArts at MIT-Multics
Sender: COMSAT.SoftArts at MIT-Multics
Reply-To: Frankston at MIT-Multics (Bob Frankston)
To: works at MIT-AI
*from: BOB (Bob Frankston)
Local: works at mit-ai
There are many naive ideas for backup that work in limited
contexts. The assumption of keystroke backup is that the
keystrokes are the only information needed. That might be true
in simple system. It is not true when one is interacting with
a more general environment. For example, inserting files from
a hierarchy using names relative to the current environment.
Or reading mail, or waiting for timeouts.
Subject: Making paper go away
∂16-Jul-81 0704 Joe.Newcomer at CMU-10A Making paper go away
Date: 14 July 1981 1211-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: gaines@RAND-UNIX's message of 12 Jul 81 18:14-EST
You've fallen into the same trap that most people do. If what you
want is the ability to scan quickly thru a document, this suggests
that a capability the computer should have is to scan quickly thru a
document. If you want to make notes, the computer should provide the
ability to make notes. If you want to doodle in color, the computer
should provide the ability to doodle in color. What you've stated is
not reasons for retaining paper, but a specification of what
capabilities we need in a computer if we want paper to go away.
Now current technology makes a lot of this extremely difficult. For
example, at very slow data rates (say, 9600, which is as close to DC
as one would care to get), it is unreasonable to browse thru most
large documents. With 24-line screens, finding enough context to
make sense of what has been typed is nearly impossible. But saying
that online retrieval will never replace paper is silly; it means
you've failed to adapt the computer to what people need.
The observation that it is useful to print things out on paper so
they don't have to be stored online is likewise looking at the
problem from the wrong side. What I want is a method of taking silly
pieces of paper and getting them onto the machine so I don't need to
store the paper! Fact: secondary storage is cheap, is getting
cheaper, and even primitive archiving techniques make it look even
cheaper. Why should I have to do something (file a piece of paper)
that the computer can do more effectively?
I keep all my source listings in hardcopy form. Why? Because it is
faster to look something up on hardcopy than online. Why? because a
24x80, 9600 baud terminal is too small and too slow to accomodate me.
If I had four or five 60-line screens with a typical effective
bandwidth (including disk latency, etc.) of about 100Kbaud, I
wouldn't need to print anything. One way of achieving this is to use
multiple windows, but it is not the only way (another is to have four
or five 60-line terminals).
If paper is more effective, then there is a mismatch between the
needs of the person and the software. I don't see anything which has
yet made that statement even suspect. What we need to do is explore
how to eliminate that mismatch.
joe
Subject: Programming by example
∂16-Jul-81 1052 Halbert at PARC-MAXC Programming by example
Date: 13 Jul 1981 10:35 PDT
From: Halbert at PARC-MAXC
To: WorkS@mit-ai
Here is a short description of programming by example. I
have gotten requests from a LARGE number of WorkS subscribers
requesting it.
------------------------------
Since a few people have mentioned programming by example and
the work I've done on it specifically, I will try to give a
brief outline of what it is, and what I've done:
At its simplest, programming by example is just recording a
sequence of commands to a system, so that the sequence can
be played back at a later time, to do the same or a similar
task. The sequence forms a program. The user tells the
system, "Remember what I am doing". The system executes
the user's commands normally, but also remembers them.
The user has created a program by giving an example what he
wants the program to do. However, the statements in his
program are the same as the normal system commands. The
user does not have to learn some programming language with
its attendant syntax and semantics; instead he can do his
programming -in the user interface- of the system, which he
already has to know anyway in order to operate the system.
In addition, he has written the program by performing,
concretely, an example of what the program is supposed to
do. Since he can easily verify whether he did his example
correctly, he can be fairly confident his program will work.
He does not have to understand his program abstractly.
Naturally, straight line programs without parameters are not
very interesting. Once the user has written a program he
may want to -generalize- it. He may want to print file Y,
instead of the file X he used in his example. So the system
has to provide a way for him to to change the constants in
his programs to variables, and specify how these variables
are to be bound (e.g. by prompting the user, by looking for
similar data, etc.)
The user may also want to insert conditional or looping
constructs into his program. There are various ways, which
I will not go into here, of inserting these constructs into
programs using programming-by-example techniques.
I would emphasize that this kind of programming by example
does not use inductive inference techniques used in AI,
in which the user does several examples, and the system
inductively determines what has changed from example to
example (e.g. 1+2, 5+2, hmm, first operand must be a
variable; or a[1], a[2], a[3], hmm, looks like a loop
stepping through the array).
The seminal work in programming by example was done by Dave
Smith of Xerox in his Stanford Ph.D. Thesis. Gael Curry
did similar work in which the examples given by the user
could contain abstract as well as concrete data values.
Certain industrial robots can be programmed by example by
guiding them through the task they are to perform. Here
at Xerox, I have added programming by example to a prototype
of Star. The system provides program generalization and
an iteration mechanism as well as simple command recording.
I have written up this work and my ideas on programming by
example so far in a Master's project report done for U.C.
Berkeley. I intend to continue and extend this work into a
Ph.D. thesis.
References:
Daniel C. Halbert. An Example of Programming by Example.
Master's project report, University of California, Berkeley,
and internal report, Xerox Corporation, Office Products
Division, Palo Alto, CA.
David C. Smith. Pygmalion: A Computer Program to Model and
Stimulate Creative Thought. Ph.D. thesis, Stanford University,
1975 and Birkhauser Verlag, 1977.
Gael A. Curry. Programming by Abstract Demonstration. Ph.D.
thesis, University of Washington, Seattle. Technical Report
No. 78-03-02. March, 1978.
Henry Lieberman and Carl Hewitt. A Session with Tinker:
Interleaving Program Testing with Program Writing.
Conference Record of the 1980 LISP Conference, Stanford
University, August, 1980. [describes a programming by
example system for Lisp]
Michael A. Bauer. Programming By Examples. Artificial
Intelligence 12: 1-12 (May 1979). [describes inductive
inference techniques].
Copies of my report are available on request.
Dan Halbert
Xerox Corporation
Office Products Division
3450 Hillview Avenue
Palo Alto, California
or
Halbert@PARC-MAXC (preferred)
(or csvax.halbert@Berkeley)
--Dan
-----
Subject: Re: Reliablity
∂16-Jul-81 1634 Bernie Cosell <cosell at BBN-UNIX> Re: Reliablity
Date: 15 Jul 1981 13:50:10 EDT (Wednesday)
From: Bernie Cosell <cosell at BBN-UNIX>
In-Reply-to: Your message of 13 Jul 1981 11:20 EDT
To: BHYDE at BBNG
Cc: Works at MIT-AI
I agree with Ben that the `real' accounting fellows really did figure
it mostly out (several hundred years ago!), with Journalizing and
autid trails and the like. I would like to make a tiny correction:
if I remember correctly from some accounting courses I took, double
entry bookkeeping has nothing really to do with the `journal' aspect:
the double entry name comes from the fact that both debits and credits
are simultaneously maintained and every financial transaction is fully
entered on both sides. Thus, at any moment, you can check a set of
books for a simple addition error by simply totaling up all of the
accounts and the balance should always be zero. (I think that this
is called taking a trial balance).
/Bernie
Subject: PIE reports from PARC
∂16-Jul-81 1811 Chris Ryland <RYLAND at SRI-KL> PIE reports from PARC
Date: 16 Jul 1981 1446-PDT
From: Chris Ryland <RYLAND at SRI-KL>
To: WorkS at MIT-AI
Since I've gotten quite a few requests for the PIE reports
I referenced, I'm forwarding the official requesting address
and the report identifiers:
CSL-81-3, Goldstein & Bobrow "An experimental description
based program environment - four reports" and
CSL-81-5 Goldstein & Bobrow "A layered approach to software
design" are available by sending a message to Jenkins@PARC
with your address.
Subject: Quickie poll
∂16-Jul-81 1825 Lloyd at MIT-AI Quickie poll
Date: 15 July 1981 2220-EDT
From: Lloyd at MIT-AI
To: WorkS at MIT-AI
How many people on this list are ACTIVELY hacking a personal
workstation in hopes of creating a real live 'office automation'
or 'executive information' system? I feel fairly certain that
the PARC folk are but how 'bout the rest of you?
Brian
P.S. It's OK to swamp my mailbox this time. I will pass the
results of my poll on if anyone is really interested.
B
Subject: Re: Making paper go away
∂16-Jul-81 1841 Zellich at OFFICE-3 (Rich Zellich) Re: Making paper go away
Date: 16 Jul 1981 0936-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
To: Joe.Newcomer at CMU-10A, works at MIT-AI
cc: ZELLICH
In response to the message sent 14 July 1981 1211-EDT (Tuesday)
from Joe.Newcomer@CMU-10A
Well, there is already a way to scan quickly through files:
it's called structured (or hierarchical, or whatever) files
a la Engelbart's NLS (now called Augment) and (Ted Nelson's ?)
Hypertext.
You can look at one or more levels, and independently one or
more lines of those levels, and open up or close up the part
on your screen to see more or less. It makes it very fast
to see what is in a document you've never seen before, or
to find something specific in an old document when you don't
know it's exact location. You may even be able to "address"
desired text by context. Combined with a windowing capability,
a pointing mouse, and auxiliary 5-key keyset, this gives an
extremely powerful tool - now if only it came packaged in a
briefcase-sized personal DEC-10...
Structured files are great, but do have an interface problem
because the rest of the world uses "flat" files - it's not
always easy to translate between the two - especially if there
is highly-formatted text like columnated tables, or "drawings"
(dot-and-dash boxes, etc.). Of course, the interface with the
rest of the world is a problem when using *any* advanced system
- I might have a little trouble putting a Star icon in a netmail
message, too.
-Rich
-------
Subject: Re: Making paper go away
∂16-Jul-81 1902 Joe.Newcomer at CMU-10A Re: Making paper go away
Date: 16 July 1981 1400-EDT (Thursday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: Zellich@OFFICE-3's message of 16 Jul 81 11:35-EST
One of the main problems in dealing with structured files is that
most operating systems give you "the files" and "the user space"
and you're on your own to figure out what to do with the files.
In Hydra, it was possible to define the text string transformation
of a file as part of the "subfile" type description. No matter
how peculiar the internal representation of the file might be,
the interface it provided to the outside world was a sequential
"flat" file suitable as input to a compiler or lister. Of course,
there were other interfaces which were presented; internally, the
editor for that file type was powerful enough to manipulate the
full representation. One could also have a "display" interface
by which illustrations were made visible on a CRT, or a "printer"
interface by which the file was presented in a form suitable for
printing (e.g., a Press file format would have been possible).
This is necessarily a simplified view, and we didn't begin to
explore all the problems, but the really important idea is that
at the basic interface, an ordinary program could NOT get at the
bits of the file. Only the bits presented by the file interface.
This abstraction is critical in protecting users from file repre-
sentations, and I consider any file system which does not support
at least this form abstraction to now be hopelessly behind the
state of the art.
I hope to do some more research in this area in the next few
years. The Hydra idea may NOT be the best, or even close to
right, but it is a whole lot better than any conventional file
system.
(In Unix, it is possible to use pipes to provide the transfor-
mation; a filter converts a complex file to a sequential byte
stream. Alas, Unix does not provide the protection necessary
to keep any random program from trashing the file by THINKING
it is a sequential byte stream file. Nonetheless, their heart
is in the right place. This is one of the reasons I think
pipes are a winning concept).
(The message based operating system for Spice, called Accent,
makes it possible to build systems with this style of
interaction).
joe
Subject: Making paper go away
∂16-Jul-81 1928 Vaughan Pratt <CSD.PRATT at SU-SCORE> Making paper go away
Date: 16 Jul 1981 1445-PDT
From: Vaughan Pratt <CSD.PRATT at SU-SCORE>
To: works at MIT-AI
If paper is more effective, then there is a mismatch
between the needs of the person and the software.
Joe's implication that any mismatch between people and computers
needs to be eliminated is similar to the attitude that gave rise
to the BART fiasco. This zeal to automate everything is misplaced.
Some products already do their job quite well. Paper, for example.
One thing I particularly like about paper is that I can leave
it on the beach while I'm swimming without being too concerned
that someone is likely to walk off with it. Is anyone willing to
predict which century will see portable computers able to compete
with paper as an improbable target of petty thieves?
A more appropriate attitude would be to keep an eye open for
opportunities where the computer can outperform the traditional
product. I suspect this is what Joe really has in mind when
he talks about automating paper. Paper has its disadvantages
as well as its advantages. Pen-and-paper is a poor medium
for speed of text input (many of us type twice as fast as we
write, though presumably not Steven Gutfreund, who says he
prefers mice and chordsets to 4-row QWERTY keyboards). Paper
is inconvenient to transmit, with a delay measured in days
rather than minutes. It is difficult to search associatively.
It does not lend itself to alteration. Making duplicates for
redundancy (e.g. guarding against fire etc.) is awkward.
Text and graphics macros (Letraset, stencils, french curves,
rubber stamps, etc.) are relatively inflexible. Conversion
to machine readable form is much harder than the reverse
direction.
The moral is that while computers outperform paper in some
categories, it is wishful thinking to imagine that it will
also soon come to dominate in all the remaining categories.
Needless to say, the moral applies equally well to other
products besides paper, e.g. BART drivers.
Applying this to AI, I would prefer to characterize AI
not so much in terms of passing Turing's test as looking
for additional human activities that lend themselves to
automation.
Subject: Re: Office of Tomorrow, where is it?
∂16-Jul-81 1947 Joe.Newcomer at CMU-10A Re: Office of Tomorrow, where is it?
Date: 14 July 1981 1222-EDT (Tuesday)
From: Joe.Newcomer at CMU-10A
To: DREIFU at WHARTON-10 (Henry Dreifus)
CC: works at mit-ai
In-Reply-To: DREIFU@WHARTON-10's message of 12 Jul 81 18:55-EST
I suppose you've heard of the idea of putting 2GHz packet
transmission repeaters on every commercial aircraft? The idea
is that there is hardly a moment when there isn't at least one
aircraft over someplace in the U.S., so the number of times
you would find the global network unavailable to your pocket
terminal should be fairly small...and of course, if you are on
the airliner, you should be able to use the facility as well.
joe
∂16-Jul-81 2007 Chip Maguire <Maguire at UTAH-20> Re: Office of Tomorrow, where is it?
Date: 13 Jul 1981 1617-MDT
From: Chip Maguire <Maguire at UTAH-20>
Subject: Re: Office of Tomorrow, where is it?
To: DREIFU at WHARTON-10, works at MIT-ML
cc: Maguire at UTAH-20
In-Reply-To: Your message of 13-Jul-81 0745-MDT
Over two years ago I spoke with the North American VP of
a large European airline, he was looking toward terminals
in the airplanes for both passanger use and for airline
reservations/info (because of the high degree of being late
screwing up large numbers of passengers schedules - let the
passengers change their reservations while circling JFK or
when making that suprise landing at Moline). His company
was also thinking of utilizing TELETEXT for reservations
in cities offering this service.
Chip
-------
∂16-Jul-81 2023 JWALKER at BBNA Re: Office of Tomorrow, where is it?
Date: 13 Jul 1981 0934-EDT
Sender: JWALKER at BBNA
Subject: Re: Office of Tomorrow, where is it?
From: JWALKER at BBNA
To: WorkS at AI
Message-ID: <[BBNA]13-Jul-81 09:34:24.JWALKER>
In-Reply-To: Your message of 12 Jul 1981 (Sunday) 1955-EDT
Why not on airplanes? Until the problems of electro-whatever
interference are more under control we won't be using terminals
on airplanes. As they explained on one flight I was on, the
kiddies couldn't use their electronic games because they
interfered with the plane's navigation equipment. So I think
it will be awhile before we beam communications out of the sky
to our home computers!
Subject: Icons and analogy
∂12-Jul-81 1804 BHYDE at BBNG Icons and analogy
Date: 10 Jul 1981 2252-EDT
Sender: BHYDE at BBNG
From: BHYDE at BBNG
To: Works at MIT-AI
Message-ID: <[BBNG]10-Jul-81 22:52:13.BHYDE>
It is not difficult to develop a sympathy for the
earlier comment that it seems sad to adopt as a primitive
of the automated office all of the curious mechanism of
the traditional paper mill. Three ring binders, electric
pencil sharpeners (where ones mouse regularly visits), to
calling cards.
There is a reason for this fundamental decision being so
popular in the community. I believe that I recognize in
this choice a pattern I first saw in the product lines of
the process control companies, product offerings always
mimic existing products. This seems to be a fundamental
truth of all marketing. If a product is completely new
then your customers will not be able to comprehend it,
they will not recognize it, it will be foreign, odd ball.
In the real time control community a very popular device is
the programmable controller, it replaces a relay controller,
its operation is specified with relay ladder diagrams. It
is implemented with a microprocessor, programmed on a video
terminal. The video terminal is often specially constructed
to be able to draw the ladder diagrams. I have heard sane
and successful providers of these devices talk of the new
model that includes as a standard component a speaker which
will generate the simulated noise of the relays clicking.
Once installed the plant foreman will never notice the
difference.
In creating a successful product one has to sell too many
groups of people, technical management, business management,
sales management, the sales men, and lastly the customers.
Each to these groups must be taught. Taught enough so that
they feel warm and comfortable about this new (and hence
suspect) product. If one can explain the product via analogy
then their rich body of experience ( hence trust ) with the
analogous situation can be used to leverage the short period
of time available to train them in.
What is this they cry! If you can't answer in one sentence
the sale is lost.
Ben Hyde
Subject: Redefining the art
∂13-Jul-81 0712 Brian P. Lloyd <LLOYD at MIT-AI> Redefining the art
Date: 12 July 1981 12:42-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
To: WORKS at MIT-AI
Yes, there are significant marketing reasons for not changing
the state-of-the-art too rapidly. Fortunately we do not need
to concern ourselves with what the customer expects. Look
at Xerox-PARC and the Alto system: I don't think that they
concerned themselves with market acceptance when they first
designed the Alto. Their experiences have brought them to the
forefront of the personal workstation and office automation
marketplaces. Ok, I accept "Star" as the current SOTA. I now
want to know what lies beyond. On a day-to-day basis I have
to stifle my creative urges in order to satisfy the needs of
a marketing organization. In this forum I want to discuss
future concepts.
Brian
Subject: Re: Re: A Quibble or two
∂13-Jul-81 0810 gaines at RAND-UNIX Re: Re: A Quibble or two
Date: Sunday, 12 Jul 1981 16:14-PDT
To: Joe.Newcomer at CMU-10A
Cc: works at MIT-AI
In-reply-to: Your message of 7 July 1981 1218-EDT (Tuesday).
From: gaines at RAND-UNIX
.... If using little pieces of paper is more effective than
using the computer, this indicates that something is very
wrong in the design of the software. Either the software
is good enough to replace paper, which is presumably the
intent, or somebody blew the design.
This implicitly states the view that paper is going to go away.
I don't believe it. As computer use increases in offices, I
think that we can expect that the amount of paper shuffled
will substantially decrease. But paper has its own uses. It
is easier to scan rapidly through a large report (or a printed
collection of junk messages from the Arpanet) that to do the
same on-line. It is wonderful to be able to write or draw, in
colors, on a printed page, including on top of the writing. I
can often find interesting things in a file cabinet when I'm not
sure just where I filed it than I can find things filed on-line
when I am faced with the same degree of uncertainty. I expect
that the evolution of office work brought on by intensive use of
computer works stations will cause many changes which affect how
and when paper is used, but will not eliminate it.
Incidentally, the one thing really needed is a cheap way to
read in a computer-printed piece of paper, so I don't have to
maintain the corresponding text on-line. If we had really cheap
large capacity stores so that things could stay on-line forever,
then it would be nice to copy anything printed to a retreivable
place, with the identification automatically printed on the piece
of paper so that if I delete it from my files, I can retreive it
again when I next look at the piece of paper.
Overall, I think we need more progress on getting the paper
and computer worlds to mesh together nicely, in contrast to
the objective of getting rid of paper.
Subject: Re: Spatial design for a workstation
∂07-Jul-81 0556 JWALKER at BBNA Re: Spatial design for a workstation
Date: 6 Jul 1981 2102-EDT
Sender: JWALKER at BBNA
From: JWALKER at BBNA
To: WorkS at AI
Message-ID: <[BBNA] 6-Jul-81 21:02:05.JWALKER>
In-Reply-To: Your message of 1 Jul 81 10:03:14-EDT (Wed)
My initial reaction to your scenario is that the idea of selecting
an operation is no different in essence from continuing a suspended
operation. E.G. selecting INBOX is exactly the same as continuing
a mail reader. The distinction is in being able to reinstate visual
context. This is an important distinction of course, being made
feasible by the new generation of hardware for displays.
One question though. This scenario description assumes that each thing
you can select has one "reason" for being selected. The INBOX being
selected means you are rummaging through it. Is this assumption likely
to hold? That is, will the reason for selecting something always be
unique or unambiguous enough that the right set of operations will
become available automatically?
Jan
∂07-Jul-81 0650 Zellich at OFFICE-3 (Rich Zellich) Re: Spatial design for a workstation
Date: 6 Jul 1981 1731-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Re: Spatial design for a workstation
To: WorkS at MIT-AI
I currently use a system that keeps track of the previous infile locations,
the previous file(s), and the previous programs/tools. It is very
handy to be able to do this, but it *does* have some drawbacks. One is
that there is a finite number of such things that can be kept track of,
so occasionally you lose track of the nth-back thing (the computer does,
anyway - you may still remember it yourself); the other main drawback is
that sometimes you *don't* want to keep track of everything you just did.
You can't win, really. Either the system tries to keep track of *everything*
and makes it really confusing to go back through the ring structures after
being online for a couple of hours, or the user must issue an
explicit command to either "save" or to "don't save" when interrupting to
somewhere else.
-Rich Zellich
-------
∂07-Jul-81 0721 DPR at MIT-XX Spatial design for a workstation
Date: Monday, 6 July 1981 09:39-EDT
From: DPR at MIT-XX
To: Rivanciw.DHQ at UDel
Cc: works at Mit-Ai
Subject: Spatial design for a workstation
Congratulations. It seems that you have just discovered the paradigm
of the Xerox STAR and Negroponte's Spatial Data Management systems. More
likely you knew about them already. With a little improvement in
Xerox's software, this could be the substance of an ad for STAR!
THe problem, though, is the same as the one on my desk--it get cluttered
fast with incomplete tasks. If certain tasks have long time horizons,
and certain ones have short time horizons, the result is a mess. If the
priority is not correlated with time horizon (since in my case there is
always more to do than can be done, requiring that some things NEVER
get completed), then the pile gets deeper and deeper. So now I need
three dimensions, and a way to hand tasks off to others in a partially
completed state if it looks like I won't be able to finsih them.
How does my secretary extract stuff from my "automated desk" and finish
it when I'm out--or conversely, how do I or a temp deal with her "automated
desk" when she's sick?
David
∂07-Jul-81 0748 Deutsch at PARC-MAXC Re: Spatial design for a workstation
Date: 6 Jul 1981 07:53 PDT
From: Deutsch at PARC-MAXC
Subject: Re: Spatial design for a workstation
In-reply-to: Rivanciw.DHQ's message of 1 Jul 81 10:03:14-EDT (Wed)
To: Rivanciw.DHQ at UDel
cc: works at Mit-Ai
As I mentioned before, the concept you mention is exactly the one that has
evolved at Xerox over the last 10 years and is (I believe) incorporated in
the Star in a form very similar to the one you envision. Of course, your
scenario includes a good deal more "polish" than the Star in terms of the
system being more intelligent about the relative priorities, default
desires, etc. of the user.
Subject: Re: Spatial design for a workstation
∂07-Jul-81 1035 cfh at CCA-UNIX (Christopher Herot) Re: Spatial design for a workstation
Date: 6 Jul 1981 13:06:26-EDT
From: cfh at CCA-UNIX (Christopher Herot)
To: Rivanciw.DHQ at UDel
Cc: works at Mit-Ai
In response to your message of Sun Jul 5 14:23:05 1981:
We built a system here for ARPA which incorporates
some of the facilities you describe in your scenario.
The system consists of a number of intelligent (8080-based)
terminals hooked up at 9600 baud to a PDP-11/70 running
Unix. The screen provides a window into a data surface
which contains icons of various shapes. The outlines of
the icons are made up of standard printing characters.
The user can scroll the data surface by pressing an arrow
key (8 are provided to allow diagonal motion) or an
outboard joy stick.
The icons are user-defined and can correspond to any
program runnable under Unix. To run the program, the
user centers its icon on the screen and presses an
"activate" button. Typically, the program to be run
is the Ned (Rand ->BBN) display editor editing some file.
The user can return to the top level via either of two
buttons - "deactivate" or "detach". The "detach" button
suspends the program and causes the icon to blink. When
the user again activates that button, the screen is restored
to its previous state. I agree that it would have been
better to make "detach" the standard mode, but this was
not practical under Unix with the implementation approach
that we had chosen.
We haven't tried the system in an actual office environment.
Programmers found it cumbersome because there was always a
Unix command that didn't yet have an icon, and they already
knew most of the command names anyway. It usually took more
time to scroll to the icon than to type its name. People
always enjoy the demo however, and we are still looking for
a place to try it out.
Subject: Collected responses on terminal input devices
∂19-Jul-81 1612 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on terminal input devices
Date: 19 July 1981 10:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
This collection of 9, relatively short messages continues the
WorkS discussion of interchangeable keyboards, touchpanels,
and other terminal input devices.
Enjoy,
RDD
------------------------------
Date: 17 July 1981 12:17-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: chordsets
To: csd.pratt at SU-SCORE
cc: WORKS at MIT-AI
Actually I don't know how I would feel after using a chordset
all day. What I am interested in is finding an alternative to
QWERTY input. There must be something with better ergonometrics
than a matrix of keys laid out to suit 18th century designers
of mechanical devices.
- Steven Gutfreund
------------------------------
Date: 18 July 1981 07:50-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
Subject: Interchangeable keyboards
To: SHRAGE at WHARTON-10
cc: WORKS at MIT-AI
The Convergent Technologies system has the ability to change
the keyboard encoding and the font on the display. We have
experimented with AZERTY, Dvorak, and special purpose
keyboards. We have used the unencoded mode of the keyboard
to simulate a chord keyboard. The only thing we lacked was
a simple way to relabel the keys (do you have any concept of
how difficult it is to make 98 little self-adhesive labels
and stick them on your keyboard every time you make a change?).
I would be interested in the re-label-able keyboard if you get
more info.
Brian
------------------------------
Date: 18 Jul 1981 (Saturday) 1148-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
Subject: LCD interchangeable keycaps.
To: lloyd at MIT-AI, works at MIT-AI
Well, let's let our imaginations run wild for a moment. It might
be possible to construct a 50x50 (or even less could do it) LCD
display with individually addressable points. Since the time
that an LCD takes to fade is very long, a rather slow Z80 would
be able to keep up with the updating of 50 or 60 of these. The
problem is really in fabricating the LCD and in wiring the keys
since there would have to be all these wires to each key (LCD is
not XY addressable as far as I know). The trick is to minimize
wires to the key. Typically this is done by putting encoding
onboard (onkey). Then we would only need two or three wires to
each key. I would think that if someone set their mind to it the
technology exists to do this job right.
Here are two other alternative in case you don't happen to have
an LCD fabrication plant in your back yard:
(1) put LCD strips just above the separated rows of keys. The
problem here is that the separation of the keys could make
it rather difficult to type.
(2) Train people to type on totally blank keys by reading a
"keyboard icon" that is ALWAYS displayed at the bottom of
the screen. This is my favorite idea and I'll bet that it
is not hard to so train typists. Well, give it a try and
let me know what you discover.
-- Jeff
------------------------------
Date: 18 July 1981 23:17-EDT
From: Brian P. Lloyd <LLOYD at MIT-MC>
Subject: LCD interchangeable keycaps.
To: WORKS at MIT-MC, SHRAGE at WHARTON-10
CT has an interesting keyboard diagnostic along the lines you
proposed. The program displays a facsimile of the keyboard on
the screen, and echoes what you type by turning the corresponding
key reverse video. It even shows whether or not the LEDs on
the keys are lit. I see no reason that this display couldn't
be shrunk and placed in its own window at the bottom of the
screen.
Good idea you had!
Brian
------------------------------
Date: 16 Jul 1981 20:53:37-PDT
From: CSVAX.rob at Berkeley
Subject: Tablets, mice, etc.
There is a very nice tablet available from Kurta Corporation
(206 S. River Dr., Tempe, Arizona, 85281 (602)968-8709). It
comes with either a parallel or serial interface, so if you
choose you needn't decode 9600 baud ASCII (a major break-
through...). It's about 8"x11", and if you ask for the Bell
Labs cursor you'll get a 3-button cursor much like a mouse.
We have a couple here, and are pleased with them. People
using them mostly feel they prefer the tablet to a mouse.
Rob Pike (research!rob@berkeley i think. or (for sure) robt@mit-mc)
------------------------------
Date: 17 Jul 1981 18:44:25-PDT
From: decvax!duke!unc!smb at Berkeley
To: duke!decvax!ucbvax!WorkS@MIT-AI
Subject: touching mice
I'm not too crazy about any of the pointing systems I've seen
described here, because I don't like having to take my hands
off of the keyboard. Besides, menus tend to have too few
options (can you imagine a menu for the UNIX command set) and
they impede the user who knows what he/she wants to do next.
But there seem to be enough folk out there who LIKE to worship
icons, so.... an idea I've seen suggested for a pointing device
is a light pen that's worn as a thimble or attached to a ring.
One must still remove a hand from the keyboard, but at least
there's no need to grope for squirmy mice. This idea works
best, it would seem, in situations where there's a fairly
large amount of pure text work, as well as commands -- say,
a text editor.
--Steve Bellovin, UNC, Chapel Hill
------------------------------
Date: 16 July 1981 13:54 edt
From: MPresser.Multics at MIT-Multics
Subject: Tracking balls
To: WorkS at MIT-AI
In-Reply-To: Message of 15 July 1981 09:32 edt from Joe.Newcomer
I have used a reasonably good tracking ball on a system that
did the automatic recognition of human chromosomes. Every
so often, the system would get confused and not be able to
separate two chromosomes that were, or appeared to be touching.
The ball was used like a scissors to cut the surface, so that
two disconnected objects appeared. Our ball was homemade, and
the most circuitous of cuts to be made in next to no time.
The principle used was that of extreme gearing down, so that
very fine motions could be made. For these purposes, the
thing was very useful. I'm not sure how it would have worked
for menu manipulation. We used the terminal keyboard for that.
------------------------------
Date: 16 Jul 1981 0924-PDT
From: Chris Ryland <RYLAND at SRI-KL>
Subject: Bill Park's message
To: WorkS at MIT-AI
In-Reply-To: Your message of 16-Jul-81 0400-PDT
Bill Park's message mentioned what I believe XEROX marketed as a
"cat" on the 850-series word processors: a small area which you
stroke to move the cursor. Since these systems were fixed-font
oriented, I don't know if these cats would be useful in a more
high-resolution environment.
------------------------------
Date: 18 Jul 1981 (Saturday) 1110-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
Subject: Visionary terminals
To: minsky at MIT-AI, works at MIT-AI
If you sneeze does it blow all the icons off the screen?
------------------------------
End of collected responses on terminal input devices
****************************************************
Subject: Bell Labs "writers workbench"
∂19-Jul-81 1613 mike at RAND-UNIX Bell Labs ''writers workbench''
Date: Saturday, 18 Jul 1981 12:43-PDT
From: mike at RAND-UNIX
To: works at MIT-ML
As has been mentioned, Bell Labs has put together a "writers
workbench" which is a set of tools to help detect and correct
common errors. Along with a spell program, there is also a
program to correct "bad diction", along with an "explain"
program which acts as an interactive thesaurus.
If you are interested, send me a message and I will forward
off the manual page.
Michael
Subject: writing aids
∂19-Jul-81 1614 Lauren at UCLA-SECURITY (Lauren Weinstein) writing aids
Date: 18 Jul 1981 0218-PDT (Saturday)
From: Lauren at UCLA-SECURITY (Lauren Weinstein)
To: ELLEN at MC
CC: BUG-EMACS,WORKS at AI
While I cannot help you with EMACS, there is a package of
programs running under Unix called, I believe, the "Writer's
Workbench". These programs do all sorts of neat tricks, like
looking for "awkward" sentence construction, overused or trite
words and phrases, and all sorts of similar actions. Kinda neat.
--Lauren--
---
Subject: Realtime proofreaders
∂19-Jul-81 1615 SHRAGE at WHARTON-10 (Jeffrey Shrager) Realtime proofreaders
Date: 18 Jul 1981 (Saturday) 1130-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: ellen at MIT-XX, works at MIT-AI
I think that one would lose a great deal of the effect of "offline"
proofreading if the system did much of that work in realtime which
the text was being entered. The clearest argument against that type
of system is that you are supposing that the errors are entirely
detectable from PREVIOUS context. Why should that be so? If you
are not assuming that then at what point do you extract and test?
Coherence is not a clearly distinguishable effect at any given level
(sentence, pgh, etc). Additionally, coherence and intention are
understanding effects. It is not clear that they can be extracted
without a rather fancy knowledge acquisition and utilization system
-- not to mention a grammar and semantics analyzer to front end the
thing (neither of which we are very comfortable with yet). Lastly,
more concretely, having a lot of little aid demons around it okay to
a point. You have to avoid the mistake that Twenex makes in being
overhelpful -- I wish that I could disable the space-delimiter help
system that keeps telling me that TPYE is not a legal command before
I've had a moment to back up over it and fix it!
Subject: Configuration
∂19-Jul-81 1617 BHYDE at BBNG Configuration
Date: 16 Jul 1981 1445-EDT
From: BHYDE at BBNG
To: WorkS at MIT-AI
Message-ID: <[BBNG]16-Jul-81 14:45:00.BHYDE>
There seen to be a clusters of similar designs for work stations.
One group is into bit slices and microcode tuning of instruction
set and i/o drivers. Another group seems to be into integrating
state of the art leading edge lsi and i/o devices into an expensive
terminal/computer ala 68000, winchester, and bit map. A smaller
group seems to be into building (the low rider community) super
personal machines a small cluster of 6809 which is a very smart
terminal mostly.
Is there a right answer here?
There seem to be various configuration control designs, the
strongest group seems to be big into 10 Megabit shared medium.
Why is 1 Megabit not good enough, what's wrong with 9600 baud
phone connections, what is so hot about shared medium designs
verses say a local store and forward design with twisted pair?
I don't understand how the configuration problem got standardized
to 10 Megabit shared medium so quickly?
People seem to be very excited about getting rid of the computer
center. I remember the pleasure of discovering that some one
else worried about backup, maintenance, selecting the standard
editor, etc. I believe these places have been called centers
of excellence. The work station architecture seem to be going
in the other direction, for what I believe are marketing reasons
not technical ones. Are there technical ones?
Are new forms of service centers going to appear in the
community? Are we going to see a high speed/quality printing
center in Chicago with one day mailing turn around and very
low cost per page? Are we going to see file backup whales
offering competing cost per bit archiving spread around the
nation? Federal expressing a four color document would add
very little to the cost of a hundred page one time printing.
If I offered a intercity file transfer with one day delivery,
and very low cost would there be any buyers?
All of these questions are the same meta question, how are
systems like this going to be configured, at the office level,
facility level, city level, and national level. Where will
the economies of scale fall out? What is the unit dollars
available at each layer?
Ben Hyde
Subject: [don: EP]
∂18-Jul-81 0044 Dave Crocker <dcrocker@udel> [don: EP]
Date: 17 Jul 81 12:49:40-EDT (Fri)
From: Dave Crocker <dcrocker@udel>
To: WorkS at Mit-Ai
cc: Don at Rand-Unix
Don Waterman has done work similar to Halbert's and said he
would not mind my forwarding the enclosed citations.
Dave
----- Forwarded message # 1:
Date: Thursday, 16 Jul 1981 16:09-PDT
To: Halbert at PARC-MAXC
Subject: EP
From: don at RAND-UNIX
Dan: I saw a brief description on your Exemplary Programming work
and thought you might be interested in similar work done here at
Rand a few years ago. The references are:
Waterman, D. A., Faught, W., Klahr, P.,Rosenschein,
S., and Wesson, R. Design Issues for Exemplary
Programming. In Automatic Program Construction
Techniques, Biermann, G., Guiho, G., and Kodratoff,
Y. (Eds), MacMillan, In Press.
Faught, W., Waterman, D. A., Rosenschein, S., Gorlin,
D., and Tepper, S. EP-2: A Prototype Exemplary
Programming System. Rand Report R-2411-ARPA, 1979.
Waterman, D. A. Exemplary programming in RITA. In
Pattern-Directed Inference Systems (D. A. Waterman
and F. Hayes-Roth, Eds.). Academic Press, New
York, 1978.
plus a few others. I can send you copies of the papers if you
are interested.
Regards,
Don Waterman
----- End of forwarded messages
Subject: Alternatives to making paper go away
∂18-Jul-81 0106 SHRAGE at WHARTON-10 (Jeffrey Shrager) Alternatives to making paper go away
Date: 16 Jul 1981 (Thursday) 2305-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: works at MIT-AI
An alternative to hierarchical file structures for quickly perusing
bulk data: We once tried to implement a fancy solution to this
problem on a rather fancy piece of VG 3-D graphics equipment. Hook
the Z axis into the velocity of a joystick so that the faster you
move the farther away from the text you get. [Actually it isn't
quite as simple as that -- there are various tuned lags that have
to be implanted in order to give the user a chance to respond to
the modifed view, etc]. The effect is that of flying a helicopter
over your text and automatically zoom down for a close up when
you've decided that you're in the right part. I have never seen
a device less fancy than the VG that can respond and redraw quickly
enough to do this properly. The VG is a very high speed vector
graphics display that isn't really built for text work. It has a
stylus pad/light pen/knobs/buttons/full+keyboard (sorry, no meta
keys)/ and the nicest vector display around but it's really for
pictures, not text -- shame about that. Anyhow, we started to
do this and I got sick of having to deal with Fortrash and the
VG internal coding language after about a week so it never "flew"
but it was a nice idea. The real advantage is in reviewing huge
chunks of text (like the Unix manual) that are in some order (say,
alphabetically) because the text is still in front of your face
but the letters are smaller (and you get more of them on the page)
when you zoom out.
Subject: Re: Making paper go away
∂18-Jul-81 0130 Joe.Newcomer at CMU-10A Re: Making paper go away
Date: 17 July 1981 1246-EDT (Friday)
From: Joe.Newcomer at CMU-10A
To: Vaughan Pratt <CSD.PRATT at SU-SCORE>
CC: works at mit-ai
In-Reply-To: Vaughan Pratt's message of 16 Jul 81 16:45-EST
Actually, your example is quite amusing. We were recently at a
conference at Pajaro Dunes. One of our participants was walking
along the beach during one of the interludes, and left his book
on the beach while he went into the water. When he came out, he
found that someone had stolen his book.
Yes, paper is more effective for some things RIGHT NOW. While I
don't believe automating blindly is a good idea, for most values
of use of paper I would prefer to use a computer. Even if I
produce hardcopy so it can be carried around, read on beaches and
busses, etc., I prefer to produce it via the computer. There are
lots of cases where paper is more convenient ONLY because of limi-
tations of the computer (e.g., 9600 baud slow lines). And when
computers will cost only $8.95 (or free with a deposit of $500),
there will be far less reason to walk off with one. We have to
quit thinking as if computers will always be expensive, and decide
what we can do with them when they are not. In fact, assume the
cost of the computer is ZERO. Now, what would you LIKE to do with
a computer? What capabilities should it possess at the interface?
Assume a communication cost of ZERO. How would you like to commu-
nicate with other computers? Now, at any given instant we have
to temper these ideas by the rather nasty fact that computers and
communications really do cost money. But that should NOT limit
our imaginations. A Dorado is a good example of what happens if
you let ideas not be limited by technology, and technology comes
along. Things which were unbelievably bad to run on an Alto run
just fine on a Dorado.
Don't tell me automating everything is bad. I don't believe it.
Automating everything INCORRECTLY is bad. I'd rather worry about
how to do it right, even if right isn't possible, than to not
think about the problem because this year's technology can't
support it.
joe
Subject: Scanning structured text
∂18-Jul-81 0150 Bob Hyman <HYMAN at DEC-MARLBORO> Scanning structured text
Date: 17 Jul 1981 1447-EDT
From: Bob Hyman <HYMAN at DEC-MARLBORO>
To: works at MIT-AI
Message-ID: <"MS5(1715)+GLXLIB1(1033)" 11744780684.17.399.17489 at DEC-MARLBORO>
The static structure of text rarely matches its "content",
except for artificial cases like program sources. Most
of the time, the salient features of a document, which
are the ones I'd like a structured editor to key on, are
dynamically defined by the reader. Until such a symbiotic
system is available, the artificially imposed structure
of the presentation is likely to impede comprehension,
not expedite it.
The alternative is to agree on a canonic form for a class of
documents, and for authors to conform their contribution to
the mold. This solution makes discussion of the canonic form
difficult, and is probably sufficiently restrictive to repel
prospective contributors on other topics as well.
Bob
Subject: Editing
∂18-Jul-81 0211 V. Ellen Golden <ELLEN at MIT-MC> Editing
Date: 14 July 1981 03:12-EDT
From: V. Ellen Golden <ELLEN at MIT-MC>
To: BUG-EMACS at MIT-MC, works at MIT-AI
cc: ellen at MIT-XX
As is often my occupation, I am indoctrinating a new user to
EMACS. She (factual, please do not accuse me of sexism) asked
after a couple of hours of EMACS-power, if it would be possible
for "it" ("The Computer", i.e. a program) to warn her while she
is typing a text, that she has used the same word repeatedly.
I pointed out to her that (a) many words in English repeat because
they are common (parts of the verb to be for instance) (b) some
words need to repeat, like "pathologist" because of the technical
nature of the text, and thus to chose between "facts" and "data"
in discourse might be hard, or to warn her that in the last two
paragraphs the word "experimental" had repeated 6 times might not
work. However, her problem is understandable in English terms:
she is typing up notes for a doctor. He wants to write "well",
which to him means not to repeat himself, which means not using
the same word over and over again, unless it is a technical term
(a distinction he may recognize but I am not sure). His hard-
working secretary is trying to help him, and now that she knows
how much EMACS can help her in just the typing up of his notes,
she is asking for what she sees as the next step, a program
to help her with editorial corrections... (i.e. "How many
times have I used "practical"... should I get out the thesaurus?"
-- next step of course is to provide the thesaurus, but let's
concentrate on repetition of non-common but non-technical words
in text).
Any thoughts on this?
And my comment, to everybody, "BUG-EMACS", and "Work Stations":
See, secretaries are NOT a sub-species of homo-sapiens, they in
fact often request the most sophisticated features from their
editors, justifiers, work stations, etc. In fact, some of them
are even willing to work on programming the features they want
(they do know the specifications, after all!).
Subject: Writing English
∂18-Jul-81 0230 JWALKER at BBNA Writing English
Date: Tuesday, 14 July 1981 22:34-EDT
From: JWALKER at BBNA
To: Ellen at XX, WorkS at AI
CC: Bug-EMACS at AI
I have for several years wanted to write a system with the goals
you described in your note to Bug-EMACS and WorkS. (No funding
has materialized though.)
Some work has been done on the problem by people at Bell Labs.
See the paper by Lorinda Cherry in the June issue of SIGPLAN
Notices. Still the real problems are those that you pointed
out. How can a computer know your reasons for word choice?
What is it possible to do without trying to implement a system
that "understands" free text? (Good writing is more a matter
of taste than of strict rules. Of course, if mediocre writers
follow a set of strict rules, they are more likely to produce
good writing than if they ignore the rules. But that's part
of a different argument.)
I have a few EMACS functions that were designed to help in
finding and correcting common problems -- changing "which"
to "that" (if you care) and "may" to "might" or "can" (may
is ambiguous). I'd like to hear from other individuals who
have written functions to help with the job of writing as I
am working on a technical writing environment.
Jan
Subject: Ideal word-processor
∂18-Jul-81 0250 Robert Elton Maas <REM at MIT-MC> Ideal word-processor
Date: 15 July 1981 03:14-EDT
From: Robert Elton Maas <REM at MIT-MC>
I wish EMACS/RMAIL had this, but maybe if I suggest it this
feature will be installed in some future text-processing system:
You're rapidly typing new text into this editor program. As you
type, in parallel with your typing, the spelling&grammar-corrector
is checking your text. When it finds an apparent error it flags
the error and indicates alongside it a suggested correction.
Any time you want, without having to manually put the cursor back
there and manually make the correction, you may enter one of three
commands:
Stet (ignore the error, let it stand without correction)
Ok correction (make the correction it guessed at)
Repair manually (automatically put cursor there, then you
manually fix it however you want, then if the spelling
corrector still doesn't your fix it shows its new best
guess at correction and leaves the cursor there, so you
can Stet or Ok or Repair again)
After satisfying the flagged apparent error by Stet or Ok, it
shows you the next apparent error if there is any pending; but
you may just continue typing normally if you don't feel like
handling the new apparent error immediately. If you're a bad
speller, what you'd probably do is type a half a screenful
then sit there giving the Ok command for a whole batch of
errors it found, then go back to typing. Thus you wouldn't
have to constantly check your typing to see if keystrokes were
lost or words you're not sure of were wrong. If both the word
you typed and the suggested correction were wrong, but you're
lazy (it isn't an important document nor a submission to a
mass-mailing such as WORKS, just an informal note to a friend),
you could just Stet the error if it's not too gross. You could
even let the suggested corrections roll off the screen, not
bothering to even check them for grossness, if you're really
in a hurry (thus it would degenerate to what we have now if
you choose not to actually use the info the spelling-corrector
gives you).
With a Xerox-Smalltalk style of user interface, you could easily
random-access the suggested corrections, manually fixing the
gross ones and then Steting or Oking all the others en masse.
["Automate the Business Office--How and When"]
∂18-Jul-81 0311 ROBERTS at USC-ISI
Date: 15 Jul 1981 1941-PDT
Sender: ROBERTS at USC-ISI
From: ROBERTS at USC-ISI
To: WorkS at MIT-AI
Cc: roberts
Message-ID: <[USC-ISI]15-Jul-81 19:41:39.ROBERTS>
Interesting quote (attributed to an article in the "Siemens
Review") in this month's issue of "Telecommunications" magazine,
which has an article entitled "Automate the Business Office--How
and When":
"When new functions are added to an integrated work station, the
number of system components increases negligibly because existing
typewriter keyboards already possess keys for function selection,
and the function keypad will be expanded to allow the selection
of communications forms. The flat video display, designed to sit
on the desktop, is used for text preparation with correction and
editing function, the input and output of texts into memory, and
the input and output of texts to be transmitted. The flat screen
is the input/output medium for videotex, interactive videotex,
cable television, storing data from the user's own integrated
work station, and for departmental or central data-processing
systems. Finally, it also serves as the output medium for the
picturephone and video teleconferencing, for which an additional
camera, microphone and loudspeaker are incorporated into the work
station."
Now that's what I call a workstation! Comments, anyone?
Carlos Roberts
Subject: Talking Workstations, that elusive 'external device'.
∂18-Jul-81 0338 DREIFU at WHARTON-10 (Henry Dreifus) Talking Workstations, that elusive 'external device'.
Date: 17 Jul 1981 (Friday) 2127-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-AI
o Introducing Talking Workstations, Part II in presentation series
For some time, people have been doing research and development in
speech recognition.
As the 'locator device' why not voice recognizer?
While I am in my screen editor, I could say 'INSERT' or 'UPSCREEN'
rather than the key strokes.
I could say 'SEARCH' then it would prompt me for a search string.
In addition a key should be provided to toggle this feature on
and off. Imagine a demonstration saying Search or Reverse Screen
and your presentation is forever doomed.
Comments and ideas are being explored by a research group here
at Penn in this area. We'd like to know what the Works community
feels.
Subject: mice,balls,touch-plates,pens.
∂18-Jul-81 0354 MINSKY at MIT-ML mice,balls,touch-plates,pens.
Date: 18 July 1981 01:20-EDT
From: MINSKY at MIT-ML
To: WORKS at MIT-ML, MINSKY at MIT-ML
I feel that the pen-mouse-ball discussion is reactionary --
though many of the ideas are realistic and practical. But all of
them look back to non-interactive sensors of the past. Suppose
the terminal could SEE the user -- using a couple of little
vision-boxes. Then (i) it could watch your hands. You could
point to your icons on the screen in a really natural way. A
tracking cross would permit higher resolution, and the cursor
would move at a rate, say proportional to some power of the
distance between where it is and where you point. Then, one
could use some more AI to distinguish "intentional" hand motions
from tremors, etc. A smart such box could watch your eyes and
face, too.
If you like holding a pen, that too could be wireless -- because
the vision system would track its point. Such systems could work
in three dimensions. The vision box would observe your
eye-point. When you move your head, the various windows would
move in accord with 3-d occlusions, and this would permit more on
a cluttered desk than the usual methods -- moving your head a
couple of inches to the left would uncover the next layer below
on each stack -- etc.
Given a lot of R&D, such gadgets could be made in the next few
years, and would be as important as speech inputs. We need a
"terminal vision machine" project. Also, aren't the CRT schemes
rather reactionary, if flat TV stuff is coming in the next year
or two? Instead of vertical displays we can soon have (i)
desk-surface displays for near vision and (ii) wall projected
screens for far vision.
Subject: Re: Configuration
∂20-Jul-81 0737 Steve Crocker <Crocker at USC-ISIF> Re: Configuration
Date: 19 Jul 1981 1344-PDT
From: Steve Crocker <Crocker at USC-ISIF>
To: BHYDE at BBNG, WorkS at MIT-AI
In-Reply-To: Your message of 16-Jul-81 1145-PDT
Ben,
I don't think it's a fair reading of the present situation
to suggest that computer centers are "going away" in favor
of personal workstations. A better view is that the computer
center is becoming distributed and more easily incremented.
A lot of this is dependent on the specific cost of providing
service in any given technology. Today's costs make it
relatively cheap to provide a noticeable amount of computing
power to each person in the form of an individual workstation.
This means that the cost of separate packaging is less than
the cost of multiplexing several users onto the same (large)
machine. It's quite possible for this to shift back the other
way, though not likely, in my opinion.
Several things do remain centralized, and properly so:
a) file servers, high-quality printer/plotters,
long distance communication;
b) maintenance;
c) system development (hardware and software).
Your scenario of using a service in Chicago with overnight air
service is not only reasonable but entirely usual. There are
indeed services that are expensive enough to absorb the cost
of long-distance delivery. Various forms of fancy printing,
as you mentioned, is one; transcriptions of stenographic tapes
is another. I'm sure there are others.
Getting back to individual workstations, my own view is they
offer one big plus and one important trap. The big plus is
that the economics of adding a new user to "the system" is
much clearer. The classical time-sharing environment essen-
tially forces overloading of the machine, and we commonly see
environments where only the trivial tasks can be done during
the day and the heavy-duty tasks are delayed until evenings
or weekends. Unfortunately, it's these heavy-duty tasks that
are the reason for the facility and the people in the first
place. (Yes, I know this can be seen as a straight case of
mismanagement. Nonetheless, it's where things are.) With
computation tied to terminals, it becomes essentially
impossible to add people without adding capacity. (There's
always the possibility of "sharing" workstations. This may
be useful in some cases, but it will be clear to all that
when a person does not have access to the workstation, he
does not have access to anything. Compare with today's
situation where everyone has a terminal, but that doesn't
guarantee access to anything substantive at all.)
The trap in all this is there is a far sharper limit on the
size of the task that can be carried out with a workstation.
A lot of important tasks use more of the cetral facility than
the nominal capacity that is being doled out in workstations.
That will mean that transition from a small task fitting on a
workstation to a larger task that requires a different machine
will be relatively painful.
Steve
-------
Subject: Collected Responses on Terminal Input Devices
∂20-Jul-81 0838 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected Responses on Terminal Input Devices
Date: 20 Jul 1981 08:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
------------------------------
Date: 20 July 1981 07:00-EDT
From: sdcsvax!norman@NPRDC
Msgname: norman
To: works@mit-ai
Subject: keyboards should get changed, maybe
Marvin Minsky suggests that it is unimaginative to worry about
track balls and mice, light pens and touch screens, when visual
sensors can interpret your finger and eye motions so that you
need not lift your fingers far off the keyboard. Keyboard?
You mean the good old qwerty keyboard, arranged in 1873 by the
Sholes brothers to minimize jamming of the big lever arms on
the keys as they made their way to the platen? That triumph
of technology over common sense? Well, if you want to be
imaginative, why stick with qwerty keyboards?
The answer, by the way, is not to be found by simply rearranging
the keys. It turns out that qwerty is not so bad. The scheme
the Sholes brothers used to minimize clashes put the keys for
frequently typed bigrams far apart, meaning on opposite hands,
which we know today means faster typing. Lots of people have
fiddled with keyboard arrangements; its not worth the fuss.
Dvorak did a time and motion study analysis in the 1930's and
only improved typing speed by about 5% (some have claimed more
improvement; this figure comes from experiment, by computation,
and by a typing simulation program that we have developed). (In
similar ways, azerty and alphabetical arrangements don't lead to
much difference -- about 2 to 5% decrement.) And several studies
of beginners using alphabetically organized keyboards show no
improvement over qwerty. (Paper available on request.)
The current keyboard is hard to learn (several months to get to
speed), a surprisingly large proportion of people in this country
cannot type, and the top speed is limited by a combination of
physiological/anatomical factors and keyboard layout. Chord key-
boards, as used by court stenographers, go considerably faster
(they type syllables, with several simultaneous keystrokes), but
this takes even longer to learn (years), and it isn't easy to
decode as the users develop their own code for many words.
(On-line decoding can and has been done.)
BUT, why have 4 rows of keys? Why have a space bar that takes
up the whole row and is used only by the right thumb? Why not
allow upward movements as well as downward ones to be meaningful.
Why not allow multiple strokes to have meanings. Why so big?
The current size and the funny diagonal layout is determined
by historical mechanical constraints and violates the natural
mirror-image symmetry of the hands. Fitts law states that the
time to move the hands is linearly related to log(D/P) where
D is the distance to be moved and P the precision required.
You will gain a lot if the keyboard is made smaller and if
sloppiness in target location is allowed. Eliminating the
need to type RETURN on a line can speed up typing a much as
30% (our high speed films show the hand must distort itself
rather badly to get to the RETURN).
Would speech input be easier? Probably not, but a combination
of a sophisticated keyboard plus speech might be very effective.
How about tiny mice mounted on the keyboard where the thumbs can
reach them, or worn on rings, or available on a "roof" just above
the keys so that lifting the hands a fraction of an inch contacts
them. Or consider inserting the hands into gloves (wear your
keyboard) with touch and force sensitive fingertip sensors and
let hand configuration select the word and/or cursor placement.
And so on. The point is, it is time to change the keyboard,
and not just by rearranging the keys; that won't buy anything.
don norman (norman@nprdc or ucbvax!sdcsvax!norman)
------------------------------
Date: 19-Jul-81 17:08:04 PDT (Sunday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Talking Workstations, that elusive 'external device'.
In-reply-to: DREIFU's message of 17 Jul 1981 (Friday) 2127-EDT
To: DREIFU at WHARTON-10 (Henry Dreifus)
cc: Hamilton.ES, works@AI
I'd like to preserve my vocal cords, thank you. Not to mention
the fact that not everyone has a private office. I can deal
with the clack of my officemate's keyboard and the hum of his
disks, but I don't think I want to hear him muttering to his
computer all day.
I think that something along the lines of what Minsky was
suggesting would be more appropriate -- we could make much
greater use of technologies that have been heretofore
reserved for the handicapped, such as breath control, eye
control, etc. Also, I really like the idea someone suggested
a few days ago of placing lotsa special input devices just
below the spacebar. I just realized that my left thumb is
\completely/ unused!
--Bruce
------------------------------
Date: 19 July 1981 20:38-EDT
From: Marvin Minsky <MINSKY at MIT-MC>
Subject: visionary terminals
To: WORKS at MIT-MC
The general question of sneezing, etc., is interesting, and I wonder
if there is a nice theory of this: many interaction-devices separate
"pointing" and "doing". One positions a mouse and then presses an
action-button. This makes things clear to the computer, and protects
us from using signals than can be accidental. One does not often type
"DELETE *.*" as a side-effect of a sneeze.
In my vision, the AI sensing system gets better and better at telling
what you intend. In the first decade, I suppose, we'd be lucky to get
it reliably to tell where you're pointing, or what simple verbal
command you said. In another generation, it would be able to tell
when you're talking to IT, rather than someone else who just came in.
("What're you doing?" "Oh, just deleting everyone's files" -- meant
sarcastically, of course, but obeyed by the clever system.) As we
progress, the systems should grow better at telling what you really
want, and being sensible about which such intentions are plausible.
Of course, I don't believe that programming will become a casual,
natural language activity, because I don't think natural language has
adequate ways to describe an advanced programmer's intentions. (But
perhaps in a couple of generations a new order of procedural
expressiveness will indeed creep into everyday life!)
------------------------------
Date: 19 July 1981 1849-EDT (Sunday)
From: Jordan.Nash at CMU-10A
To: works at mit-ai
Subject: Terminal input devices
Message-Id: <19Jul81 184908 JN70@CMU-10A>
If we are willing to disregard cost for the moment, why not
consider pupil tracking technology as an input device. One could
simply look at the desired operation displayed on the screen and
perhaps confirm its selection by pushing a button. This certainly
eliminates the hand coordination needed for mouse input and the
sticky screen and physical exertion of the touch panel. Having
been attatched to a pupil tracking device, I realize that current
design is uncomfortable for the trackee, but I don't know enough
about the technology to throw out the idea.
Any thoughts?
/Jordan Nash
------------------------------
Date: 20 July 1981 0357-EDT (Monday)
From: Lars.Ericson at CMU-10A
To: WorkS at mit-ai
Subject: Soft Keyboards
Message-Id: <20Jul81 035716 LE60@CMU-10A>
Has anyone ever tried to build LED's right into the keytops?
This idea has always intrigued me, though it would make for
a rather expensive keyboard. Then when one wanted a new
character set, one would simply download a new set of keytop
images to the keyboard. No messy paper stickons; invent new
symbols; who knows what possibilities?
No, I do not consider a video display with a touch sensing
pad over it to be a reasonable equivalent to this.
------------------------------
End of Collected Responses on Terminal Input Devices
****************************************************
Subject: terminals versus comp centers
∂21-Jul-81 0814 Hank Walker at CMU-10A (C410DW60) terminals versus comp centers
Date: 20 July 1981 1815-EDT (Monday)
From: Hank Walker at CMU-10A (C410DW60)
To: apollo at MIT-AI
Gordon Bell has pointed out that disk drives and fancy printers
are about the only things left that have economy of scale. You
might as well chop everything else into little pieces, it makes
the incremental cost smaller.
As almost everyone on this list surely knows, comp center people
frequently tend to be power-mad, bureaurocratic, etc. Given the
choice, would you rather use the comp center or the CS department
machines?
When computing is relatively free, all arguments about wasted
cycles are bogus. You should think of your computer like your
car. Are you worried that you car is sitting idle all day
while you are at school or work? I'd think that you'd be
plenty worried if it wasn't. Are you worried that it isn't
being used at night? No. Same goes for computers.
To do fancy graphics, you need a lot of local processing due to
bandwidth. Once you do that, adding general purpose computing
isn't all that hard or expensive. If the graphics is done by a
general-purpose CPU, a la Alto, then the cost is essentially
zero.
Subject: Collected responses on terminal input devices
∂21-Jul-81 0922 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on terminal input devices
Date: 21 Jul 1981 09:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
------------------------------
Date: 20 Jul 1981 12:09 PDT
From: Kimball at PARC-MAXC
Subject: Terminal Input Devices
In-reply-to: WorkS-REQUEST's message of 20 Jul 1981 08:00-EDT
To: WorkS at MIT-AI, ALBrown
Speaking of soft keyboards, I'm surprised no one has mentioned
an old idea that has been kicking around 5 or 10 years: an image
of the keytops can be generated on the display and then reflected
off a half silvered mirror that is mounted over the keyboard.
The user can see the keys (even when his hands are over them!)
with whatever labelling he desires, switched at electronic speed.
Furthermore the geometry is such that the user doesn't have to be
exactly "on axis" to see the desired image.
Of course, there are some drawbacks, but none of them seem to be
showstoppers:
1) a lot of expensive resources (e.g. bitmapped display &
memory) are given up to support the keyboard image. Also
the image on the screen surface itself is upside down;
2) the glass "shield" over the keyboard sounds awkward;
3) I wonder whether screen curvature, raster blooming, and
the like would make it hard for the keytop images to be
precisely aligned with the physical keyboard.
Ralph Kimball
P.S. Allen Brown tells me that this concept was explored
by someone in IBM on behalf of J. C. R. Licklider
(Licklider @ MIT-XX). Forgive me if this is a garbled
pointer.
------------------------------
Date: 20 Jul 1981 1319-EDT
From: Bob Hyman <HYMAN at DEC-MARLBORO>
To: SHRAGE at WHARTON-10, works at MIT-AI
Subject: Re: Interchangable keyboards
In-reply-to: Message from SHRAGE at WHARTON-10 (Jeffrey Shrager)
of 18-Jul-81 0641-EDT
At an NCC a while ago, I saw a terminal with a dynamically
lableable keyboard. The keys were arranged in a 10 x 50 matrix,
and had transparent tops. There was a mechanical (air-driven,
I believe) sheet feeder that could slide any one of about 10
different layouts under the key matrix. The particular layout
was selected by function keys off to one side, and it took about
1/10 sec. to switch, accompanied by some hissing and clunking.
It was not an entirely unworkable arrangement.
------------------------------
Date: 20 Jul 1981 1218-PDT
From: Steve Klein <SKLEIN at USC-ISIB>
Subject: QWERTY space bar
To: WorkS at MIT-AI
If the RETURN key is in the wrong place and the full-length
SPACE bar is a waste, why not split the SPACE bar and use the
left thumb for RETURN? One would think this would not cause
too much trauma either for manufacturers or users.
------------------------------
Date: 21 Jul 1981 00:39:45-PDT
From: decvax!duke!unc!smb at Berkeley
To: WorkS at MIT-AI
Subject: keyboard tracking system
Cc: duke!shg@Berkeley
This note was sent to me; I thought I'd pass it on
>From duke!shg Mon Jul 20 09:34:50 1981
Date: Mon Jul 20 09:33:20 1981
I saw your note about a keyboard tracking system. It
seems to me that the most convenient position for a cursor
control setup is just below the space bar on the keyboard.
A small trackball or joystick modified (or even a two-
dimensional slide switch) could be easily manipulated by
either thumb without moving the fingers from the keyboard.
I find that I always use my right thumb for spacing,
thus I guess with a little practice I could use my left
thumb for cursor control EVEN WHILE TYPING.
------------------------------
Date: 20 Jul 1981 0838-PDT
From: WMartin at Office-3 (Will Martin)
Subject: Keyboards
To: works at MIT-AI
Message-ID: <[OFFICE-3]20-Jul-81 08:38:32.WMARTIN>
Keyboards: There was a LONG series of discussions on Human-Nets
some time back about Dvorak keyboards. If there are people on
this list who weren't exposed to that, maybe somebody with an MIT
account could run an editor through the HN archives and come up
with a consolidated file for FTPing of that exchange. Would be
appropriate as the list seems to now be covering alternatives to
the standard keyboard, and Dvorak has lots of supporting data
which was outlined in that discussion.
[ A transcript of the HUMAN-NETS discussion on keyboards is
available in the file DUFFEY;WORKS KEYBRD on MIT-AI. -- RDD ]
------------------------------
Date: 21 July 1981 02:12-EDT
From: Marvin Minsky <MINSKY at MIT-AI>
Sender: MINSK0 at MIT-AI
Subject: pointing devices
To: MINSKY at MIT-AI, WORKS at MIT-AI, norman at NPRDC
I agree with Donald Norman about re-examining keyboards. I
wasn't concerned with keeping hands on keyboard, because I
once learned some American Sign Language (ASL) and saw that
sign-language works quite well and could be quite fast --
provided the intelligent observing machine can keep up. One
learns a large lexicon of special words and symbols in ASL
and, when these fail one uses "finger-spelling". The latter
is lots slower than expert typing, to be sure. But this is
because one has to reconfigure the whole hand for each letter;
the vision machine could sense smaller finger changes than a
person could, I think. Then we could adopt Norman's idea
of using bidirectional finger motions, and little "chords",
etc. In the end it should be faster than typing.
Gloves and rings and things might do, but I think AI will get
around to making good seeing machines eventually, and they'll
do so many things that they'll be cheap. In the end, there
will be two or three of them inside the average typewriter,
just watching for paper jams and ribbon problems. After a
while, people will find that they don't need many of the
machines that the vision boxes were made to keep an eye on.
------------------------------
Date: 20 July 1981 1222-EDT (Monday)
From: Hans Moravec at CMU-10A (R110HM60)
To: WorkS at mit-ai
Subject: Gloves
Along with the keyboard gloves you get a head-mounted binocular
display, as in the old Utah 3D system. Now you can not only
move your head from side to side to reveal obscured pages,
but can walk around your workspace and view it from behind or
underneath. If you're into such, the entire workspace can be
mapped onto the surface of your real desk, and there can be
simulated piles of paper that look like the real thing! To
focus your attention on one, just move your head closer to it.
If the head mounted display carries outward looking cameras
that can track your fingers (and microphone and earphones),
you could pick up and shuffle the simulated paper. In the
long run all this stuff should be integrable into an
eyeglasses frame.
It needs some kind of intertial or other navigation system to
make sure it knows where your head is to generate the appro-
priate view. With a radio link to a communication system and
a shaving mirror it could be used as a videophone. Or a cheap
telepresence terminal. Or a syntha-presence unit; Imagine the
adventure display possible when you can walk around the scenes
in 3D (need a lot of crunch power for this, but much more
practical than some "holographic" methods suggested by Niven).
Better watch your icons, though!
------------------------------
Date: 20 Jul 1981 (Monday) 1804-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: In response to "gloves"
To: works at MIT-AI
It was suggested to my by Saul Levy of Bell Telephone Labs, (as
not to implicate myself) to use Teflon Boots that someone puts
their feet into, as not to have to remove one's hands from the
keyboard when typing. I leave this as a comment nothing more.
Hank
------------------------------
Date: 20 July 1981 1056-EDT
From: David Smith at CMU-10A
Subject: Pointing devices
To: WorkS @ mit-ai
In the summer of '78, I saw a demo at SRI of a device which
could tell where your eyeballs were pointed. It used internal
reflections in the lens. People were writing their names with
it. The writing was rather jerky, because the eyeballs move in
saccades. If your work station had one of those, plus a speech
(word) recognizer, you wouldn't have to remove your hands from
the keyboard to designate an icon. Lacking a speech recognizer,
you could type escape-footpedal-foo, but that lacks class.
------------------------------
Date: 20 Jul 1981 1351-PDT
From: Kelley at OFFICE
Subject: The Back Split Twist Keyboard
To: works at MIT-MC
Take the Maltron contoured keyboard. Chop it in half down the
middle. Put mice wheels under each half. Pick the portion of
the desktop you are viewing on the screen with one half. Pick
entities on the screen with the other half. No need for your
hands to leave the keyboard. Engineer a little to keep the
keyboard stationary while you type.
Now. Take a flat display screen that fills one whole surface
of a box about the size of the Whole Earth Catalog. Put your
processor in the box. On the back, place each half of the
keyboard twisted so you are holding the book while you type.
Control wheels / track ball on the side with the thumb / palm
of your hand. Control your dynabook with your back split
twist keyboard while you walk the earth.
-- kirk
------------------------------
Date: 20 Jul 1981 (Monday) 1935-EST
From: STECKEL at HARV-10
Subject: recommended reading
To: WorkS at MIT-AI
Seeing the flames and flak fly freely the last few weeks, I
would strongly recommend all participants to read the issue
of the ACM Computing Surveys Vol 13 no. 1 of March, 1981.
It addresses "human factors in computing". Especially of
interest are the article on editors and Beau Sheil's
article.
Aside, I would suggest that the ideal "terminal" look like
a pad of paper (flat screen display), with a keyboard on the
lower 1/3 or so...
g steckel
------------------------------
End of collected responses on terminal input devices
****************************************************
Subject: WorkS problems
∂21-Jul-81 1105 DREIFU at WHARTON-10 (Henry Dreifus) WorkS problems
Date: 21 Jul 1981 (Tuesday) 0950-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: WorkS at MIT-AI
WorkS has now grown to include roughly 750 people on 50 sites
across the ARPAnet. The number of topics being discussed at
any one time has increased from 1-2 to 4-5. Somewhere between
12-15 messages are submitted to the list each day. Each day's
submissions comprise approximately 15,000 characters of material.
The result is that WorkS is beginning to suffer from severe
problems. Problems which many people have begun to note.
It takes roughly 30 minutes (real time) of processing by the
mail server to redistribute one, 1000 character to everyone on
the WorkS mailing list. The amount of time required depends on
several factors. The most important factor is simply the total
number of individual message transmissions that the mail server
must do.
For example, consider the difference between distributing one
20,000 character message and 10 2,000 character messages to
WorkS. The 20,000 character message will require around 100
minutes (real time) of processing by the mail server. The 10
2,000 character messages will require 300 minutes (real time)
of processing by the mail server. Here you see the advantage
in redistributing the messages oriented around a single topic
as a collection of messages rather than as individual messages.
However, that expedient is proving inadequate to deal with
WorkS problems.
This means in all probability that WorkS will have to become
another digest mailing list. Over the next few days we'll
explain what this change entails. In the meantime we will
continue with redistributing the incoming messages in topical
collections where appropriate.
Comments/opinions/questions to WorkS-REQUEST at MIT-AI.
Hank Dreifus
Subject: Realtime proofreaders
∂21-Jul-81 1022 Robert Elton Maas <REM at MIT-MC> Realtime proofreaders
Date: 21 July 1981 09:25-EDT
From: Robert Elton Maas <REM at MIT-MC>
To: SHRAGE at WHARTON-10
cc: works at MIT-AI, ellen at MIT-XX
The advantage of automatic fixups is that you can spend your time
proofreading for deep stuff instead of proofreading for trivial
spelling errors and the like. (This is the general thing about
automation, you let the computer or other machine do the trivial
stuff so you can have more time to do a good job with the deep
stuff. FFM loosely quotes somebody named "Andre Gide", who said
"This has all been said before, but since no one was listening it
bears repeating.")
The advantage of realtime fixups, or at least flags you can
confirm later, is that the typist can detect whether something
heesh noticed as a mistake was also noticed by the computer
instead of wondering for the next hour if the post-processor
will find it; if the computer flagged it, then the typist can
safely ignore it now, even forget it, because heesh will be
reminded of it later when making a big confirm-pass thru the
document.
The problem with TWENEX is its method of flagging errors in
realtime is obtrusive. It goes ahead and makes a mess, instead
of just brightening or boxing the offending misspelled word and
letting the user move the mouse back there later to fix the word.
(Of course this is because it was designed to work on TTYs and
Decwriters, not ALTOs and other graphics-mode displays with
massive display-computing power and mouse.) Perhaps somebody
with experience on Xerox-Smalltalk on Dorado could comment on
how Xerox-Smalltalk handles errors when manually typing in
commands (instead of using the mouse to select commands from
a menu). I seem to recall you type commands into a window
and can edit them to your heart's content, then when you hit
the activation button on the mouse they are parsed and any
syntactic error is flagged, and you can edit again and again
until the parser accepts it.
Right?
Subject: File Backup
∂23-Jul-81 0031 Joe.Newcomer at CMU-10A File Backup
Date: 22 July 1981 1649-EDT (Wednesday)
From: Joe.Newcomer at CMU-10A
To: works at mit-ai
In-Reply-To: <[OFFICE-3]20-Jul-81 08:38:32.WMARTIN>
The Spice project plans to treat the local disk as a cache for
the central file system. Thus, primary backup is handled by
the same staff which backs up all our other systems. Local
disks will not have substantive amounts of private data which
is not replicated on the CFS.
In the case of workstations not on a network, if we abandon
such archaic ideas as single-task workstations, files without
timestamps, and similar absurdities, and produce some reasonably
intelligent software, a background task which does hourly, daily,
or as-needed backup to a floppy disk or other medium such as
streaming tape, occasionally prompting the use to insert a new
disk or tape, and which handles the grubby details of how to do
file retrieval in case a file restoration is necessary seems the
obvious simple solution. As I am currently thinking about having
a personal 68000-based system at home, which will not be on a net-
work, and cannot use CMU's machines for backup, this is one of the
first pieces of software I would build. My plans are to simply
assign ascending serial numbers to the floppies, and keep a file
(which is naturally backed up) which is a migration archive file
[CMU-10A users will recognize this as MIGRAT.DIR...]. Since all
REAL computers (not toy computers, no matter how powerful) have
date-time stamps which can go on files, the software architecture
is reasonably obvious.
Those ridiculous systems in which one can save or restore the
entire disk, but not do incremental save or restore, are not
worth talking about. I certainly don't want to reset my
entire disk to yesterday afternoon just because the system or
I accidently damaged one file.
More sophisticated applications, including large databases, need
more sophisticated incremental backup procedures. But these are
ALL OBVIOUS and can be ALL AUTOMATED. Using "clerical people"
or "professional people" means we've forgotten the best drudge of
history: the computer itself. The overhead on anyone to write a
serial number on an existing disk or streaming tape and insert a
fresh one is so small as to be unnoticeable. (Of course, I would
never consider the problem of "tying up the floppy drive" while
doing backup; floppies are not reasonable as secondary storage for
serious applications; they are far too small and slow compared to
even the current processors they are mated with. I consider a 10Mb
disk as small, but marginally acceptable, on a personal workstation.
24Mb is acceptable, 100Mb is reasonable. Floppies are at best a
cheap backup medium, not to be used for serious storage. I have
a small personal database which already exceeds 1Mb).
joe
Subject: Collected responses on terminal input devices
∂23-Jul-81 0228 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on terminal input devices
Date: 23 July 1981 02:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at AI
------------------------------
Date: 21-Jul-81 14:55:07 PDT (Tuesday)
From: Hamilton.ES at PARC-MAXC
Subject: Re: Terminal Input Devices
Another problem with the idea of reflecting images of keycaps onto
the top of the keys is that it prevents the use of a detachable
keyboard. Some human factors expert at NCC spent a lot of time
ranting and raving about how important detachable keyboards are.
Also, the natural touch-typing position would mean that (1) the
home-row images would be invisible because they would appear
on my next-to-last finger bones, which are angled back toward
the screen, and (2) for most keys below the home row, the image
would appear on my fingers or hands at such a distance above
the keyboard as to make the association with an individual key
rather difficult. This could even become a racial issue(!),
since presumably black people's hands don't function nearly
as well as projection screens.
All in all, if you really want to look at the keys, the key sides
are a lot more visible than the key tops, unless you're some kind
of two-fingered wonder at the keyboard.
I don't think anyone has mentioned the idea of burying a small,
high-density CRT inside the keyboard and then using fiberoptics
to route the appropriate portion of the image to each keycap.
--Bruce
------------------------------
Date: 22 Jul 1981 0941-EDT
From: Eric K. Olson <OLSON at DEC-MARLBORO>
Subject: Terminal Input Devices
It seems to me that the position of the operator's head is very
important in a scheme to reflect the key markings off a half-
silvered mirror. I have always hated things with half-silvered
mirrors anyway, because head positioning is so critical. Also,
it eliminates the possibility of a removable keyboard.
On another tack, I was discussing some of these schemes (boots,
gloves, rings, LCD keytops, etc.) with a friend here at DEC and
he was repulsed by them. He wasn't even interested in foot pedals.
Then again he has always worked for DEC (since leaving WPI), and
neither DEC nor WPI are exactly at the forefront of these ideas.
It suprises me that no-one has mentioned the possibility (seriously)
of mounting the keyboard on a (large) mouse. Mice don't have to move
a great deal to scroll the entire screen, and four mounted as the
feet of a removable keyboard could work nicely. They would need a
sticky surface and would have to require more umpf to push them (in
order to avoid false readings), but I think the idea is feasible.
For those of you in love with chord keyboards, you could mount a
mouse under one even easier.
If you think this is entirely ludicrous, I cast my second vote for
a trackball near the left thumb (perhaps cutting the spacebar short).
My VT100 does not insist that a distort my hand too much to hit the
return key (it is a selectric arrangement), and I would rather be
cursory with my left thumb. However, as my WPI/DEC friend points
out, it can be hard to use: he has a broken left thumb.
------------------------------
Date: 22 July 1981 01:41-EDT
From: Frank J. Wancho <FJW at MIT-MC>
Subject: Keyboard Augmentation
Someday, I will actually try to implement this: maybe three
footpedals, one for Shift, one for Control, and one for Meta
(Edit). I have had a sore left wrist for three months now,
and am just beginning to realize just how much I use and
contort that hand/wrist to use those keys. Footpedals would
certainly go along way to aleviate that strain.... maybe not
just three...
--Frank
------------------------------
Date: 22 July 1981 1751-EDT (Wednesday)
From: Joe.Newcomer at CMU-10A
Subject: Finger distortion
I find the backspace and escape keys even more awkwardly placed
than CR. I usually use ↑H in preference to Rubout or Backspace
because the finger travel is shorter and faster, but not all
systems treat ↑H, Backspace (which is usually ↑H but sometimes
sent as rubout, depending on your terminal) and Rubout
identically.
joe
- - - - Begin forwarded message - - - -
Date: 16 Jul 1981 (Thursday) 1503-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
Subject: Interchangable keyboards
To: works at MIT-AI
Via: MIT-AI; 18 Jul 1981 0639-EDT
I once saw design specs for a keyboard in which the keytops were
little LCD displays and were, of course, under computer control.
The types of things I can imagine doing with such a device are
virtually unlimited: Emacsify the keyboard for ↑X or ESC (Sorry,
Fineify), show keywords like various Basic systems, swap your
keyboard to APL mode with the screen, etc, etc. Does anyone
actually produce such a device?
- - - - End forwarded message - - - -
------------------------------
Date: 21 Jul 1981 21:57:41-PDT
From: ihnss!mhtsa!harpo!chico!esquire!psl at Berkeley
Subject: Talking Workstations
Have there been any measurements of the relative `work' involved
in:
a) typing "s/foo/"
b) finding a key labeled "ENTER", hitting it, typing
"foo", finding a key labeled "SEARCH" and hitting it
c) saying "SEARCH!" then saying "EFF OH OH (pause)" ?
------------------------------
Date: 22 Jul 1981 18:10 PDT
From: Kosower at PARC-MAXC
Subject: Re: mice,balls,touch-plates,pens.
In-reply-to: MINSKY's message of 18 July 1981 (Saturday) 01:20-EDT
Better yet, we could construct a box that "listens" to the
user's brainwaves (or brainstorms, as the case may be...) and
figures out from that what the user wants to do, and does it.
That way, the user would be completely spared the tedious task of
pointing. And by using a little more AI, we could construct a box
that would figure out what needed to be done (edit reports, write
programs, answer mail, etc.) and would do it without any user
intervention at all. That way, we could get rid of "reactionary"
old terminals and perhaps with the user to boot!
David A. Kosower
------------------------------
Date: 21 Jul 1981 21:56:01-PDT
From: ihnss!mhtsa!harpo!chico!esquire!psl at Berkeley
How can you call that a workstation without holocamera & odorama?
------------------------------
End of collected responses on terminal input devices
****************************************************
Subject: More on configuration
∂23-Jul-81 2309 BHYDE at BBNG More on configuration
Date: 23 Jul 1981 1116-EDT
From: BHYDE at BBNG
To: WorkS at MIT-AI
Message-ID: <[BBNG]23-Jul-81 11:16:04.BHYDE>
Let me repeat some of the phrases in the replies to my query on
configuration.
From Steve Crockers message;
"the cost of the separate packaging is less than the cost
of multiplexing several users onto ... larger ... machine."
"things do remain centralized, an properly so: file servers,
high quality printers, long distance communications, ...
maintenance ... system development ( hardware and software )"
"classical time-sharing ... forces overloading of the machine
... this can be seen as miss management... with computation
tied to terminals it becomes ... impossible to add people
without adding capacity."
"transition from small task fitting on a work station to a
larger task ... will be ... painful."
From Hank Walkers message;
"disk drives fancy printers are about only things left with
economy scale ... might as well chop everything else into
little pieces, it makes the incremental cost smaller."
attributed to Gordon Bell
"center people frequently ... power-mad, bureaurocratic."
"are you worried about you car sitting idle?"
"fancy graphics needs a lot of local processing .. (then the
cost of) ... adding general purpose computing ...(is) ..
essentially zero."
Forgive me for the paraphrasing and quotation out of context.
I find quite convincing the point that baseline services; communi-
cations, graphics processing, and packaging make the marginal cost
of a substantial piece of computing power in the office trivial.
No ones seems to argue for the demise of the computing center, I
had expected people to argue it would be replaced; on the low end
by work stations and on the high end by external service firms.
People seem to believe that central facilities, file servers etc.
will remain within the organization.
As an aside the comment about cost of multiplexing into the central
facility seems odd considering the huge increase in cost of communi-
cations that local networks imply verses front ends. Any one want
to argue the other side of that one? No one has explained to me
yet why the hugh bandwidth is a good thing in the local computing
environment?
I have believed that the leverage available in purchasing larger
machines was very substantial. If I build out of a fast expensive
technology I get a power of ten improvement in my cycles for a
linear increase in my cost. If I build out of many processors
I get a linear increase in power for a linear increase in cost.
Have I been stupid and mislead?
If this is true than, disks, fancy printers, communications, and
fancy processors will go in the central facility. The work station
design will be aligned on a cost effective boundary one up from
that amount of power necessary for graphics, communications, and
work space management.
I find the comment about cars rich in metaphorical implications;
there are many people who believe that cars are a very poor piece
of social engineering. Do organizations have more capital tied
up in the parking lot than they do inside? Unsafe at any speed?
Ben Hyde
Subject: WorkS Software.
∂24-Jul-81 0011 DREIFU at WHARTON-10 (Henry Dreifus) WorkS Software.
Date: 23 Jul 1981 (Thursday) 1928-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
To: works at MIT-AI
Part-III
The Hardware is one thing, the software is the more lasting concept.
Will the future software change? Will we see more screen-formatting
packages, better user interfaces?
What about the programmer? Source level Debuggers, complete control
of the machine (micro-code all the way to the I/O slot which is
latched to the on/off switch)?
Screen this, and menu that.
Will there be standards for screen definitions? Not at all
unlike the Core←graphics←standard we are seeing now, thanks
to VanDam and Badler and company.
Will there be "drivers" for One-User software? Distributed
power, shared computing, the questions of Queuing processes
accross machines - across the country.
Local-vs-Long Distance networks. How does one effectively
integrate this? There are more machines out today than ever
before.
The above are just some thoughts/interesting topics to get
discussions going off over all of the innovations necessary for
PersComs.
Henry Dreifus
Subject: Collected responses on useable systems
∂24-Jul-81 0036 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Collected responses on useable systems
Date: 23 July 1981 04:17-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WORKS at MIT-AI
------------------------------
Date: 23 July 1981 16:29-EDT
From: Steven H. Gutfreund <SHG at MIT-AI>
Subject: mundane
To: Joe.Newcomer at CMU-10A
Joe Newcomer raises a very good point in his letter of July-22:
I find that I have less and less time to worry about,
say, how to make CR in EMACS behave like LF and how to stop
LF from behaving differently if the previous line started at
the left margin. I know what effect I want; I don't want to
know about 37 different variables, TECO FS-flags, and other
crap to get a simple change in behavior. This is a lot of
what is involved in getting really good personal workstations;
if I have to remember dozens of incantations to, say, set up
defaults when I boot, I'm not going to be very happy.
joe
=-=-=-=-=
Peter Keene (sp?) of MIT Sloan School has a nice way of describing
the sort of system behavior Joe is looking for: mundane.
If I am not a car wizard I want my car's behavior to be mundane.
I want my car to be boring, I don't want it doing interesing things
like losing wheels. Many car drivers also don't want to learn all
the exciting things that you can do with manual transmission, boring
old automatic transmissions are good enough to get where you are
going.
If I am not a phone wizard I want my phone to be mundane. I am
not particularly interested in the intimate details of the phone
billing system when I am complaining about a $7,000 phone bill,
I really wanted the phone company to do the boring old thing and
bill me my normal ammount.
I believe that most people will want their workstations to be
mundane. They probably won't want a 3 week training course to
learn all sorts of wizzy neat features. If it behaves mostly
like those boring old office equipment (typewriters, phones,
etc.) it will probably be enough. After all, most people will
be using the workstation as a tool to get their work (what they
find interesting enough to be paid for) done.
- Steven Gutfreund
------------------------------
Date: 23 July 1981 04:17-EDT
From: James M. Turner <JMTURN at MIT-AI>
Subject: Various subspecies
To: Joe.Newcomer at CMU-10A
Shade and Sweet water,
But designing systems who's most inexperienced user is it's
lowest common denominator severely limits what can be built in
to the language.
As an example, I am currently involved in moving Scribe
to the Lisp Machine (albeit, in a greatly changed appearence).
A decision that was made very early was that although the
DOCUMENT (the Scribe input file) requires no specialized
knowledge to write, extensions to the system itself require a
working understanding of Lisp, and the way Scribe works in this
version. The idea behind this was that if we tried to create
a "secretary extensible" environment, we would be sacrificing
efficiency (important in a package which is already dangerously
slow due to LISPM <-> PDP-10 I/O speed) and clarity of code for
the benefit of people who would probably not wish to change the
code anyway.
Besides, the typical supervisor doesn't want "low level"
personnel fooling with the code anyway. A friend who is
currently doing DE for DEC related the story to me of how her
supervisor had flamed when she had poked around the OS trying
to find out how to logout (it seems SOP was to hang up, which
she could not accept).
James
------------------------------
End of collected responses on useable systems
*********************************************
Subject: Sperry Univac workstation design group -- eyewitness testimony
∂25-Jul-81 0946 SHRAGE at WHARTON-10 (Jeffrey Shrager) Sperry Univac workstation design group -- eyewitness testimony
Date: 24 Jul 1981 (Friday) 1356-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: works at MIT-AI
I was invited to Sperry's Software Research group and had an
opportunity to speak with them and examine some of the work that
they are doing in workstations and in programmer's tools. They
are more concerned with the "programmer's workstation" than a
management workstation and thus are putting a lot of effort
into the language that controls the device. It is designed to
be modified by the user and has inboard multitasking and file
system, etc. Understand that this design is for a device to be
hung from a large central machine for program developement NOT
for execution of programs. Here is a short list of the things
that (I saw) that they were thinking about/working on:
1) Pascal debugging/programming aids. They have a really nice
design (and partial implementation) for a visual program stepper
that draws colored boxes around the program structure and then
highlights the lines as they are executed so that the programmer
can "see" the program in exectution. It (will) also display
the variables and structure nicely. I played with this and it
made it very very simple to visualize what a program was doing
(especially when you turn the speed up fast enough and can see
where the loops are crunching along). The final implementation
of this should be very nice. [Jim Gimple (formerly a Snobol
afficianado from Bell) is doing this work].
2) A high res/color PWB system with joystick and mouse. They are
spending a lot of time working on the "editor language" (which
is also the JCL and workstation control language) rather than
"cutsie" features to add to the user view. The file structure
is Unix based but they ALSO feel that unix's user view is a
total lose and are designing one of their own that, from what
I saw, will be much nicer. Again, their position is that this
will be used by programmers, not managers or secretaries and
they are giving the user power to change things (in a properly
controlled manner) at whim without too much work. Currently
they are having trouble with the Univac hardware research
people (it's too slow for them) but that should be resolved
soon. This project is under control of Marc Fogel and Ira
Ruben.
3) Help systems. Knoweldge based and natural language driven (if
you like) user aids for the station command language etc. They
have several NL and AI people very interested in user assitance.
I don't know how/if this relates to the workstation but it was
interesting none-the-less. This work was being done by Nathan
Relles and Norm Sondheimer (president of the ACL).
All of the above is managed in a very small group of very expert
people by Dick Wexelblat and for more info one can write to
Sperry Univac
Software Research
2G3 Bluebell, Penna.
19424
They are going to have an Apollo and/or a couple of Perqs soon.
-- Jeff
Subject: Sperry Univac workstation design group -- eyewitness testimony
∂25-Jul-81 0946 SHRAGE at WHARTON-10 (Jeffrey Shrager) Sperry Univac wo
rkstation design group -- eyewitness testimony
Date: 24 Jul 1981 (Friday) 1356-EDT
From: SHRAGE at WHARTON-10 (Jeffrey Shrager)
To: works at MIT-AI
I was invited to Sperry's Software Research group and had an
opportunity to speak with them and examine some of the work that
they are doing in workstations and in programmer's tools. They
are more concerned with the "programmer's workstation" than a
management workstation and thus are putting a lot of effort
into the language that controls the device. It is designed to
be modified by the user and has inboard multitasking and file
system, etc. Understand that this design is for a device to be
hung from a large central machine for program developement NOT
for execution of programs. Here is a short list of the things
that (I saw) that they were thinking about/working on:
1) Pascal debugging/programming aids. They have a really nice
design (and partial implementation) for a visual program stepper
that draws colored boxes around the program structure and then
highlights the lines as they are executed so that the programmer
can "see" the program in exectution. It (will) also display
the variables and structure nicely. I played with this and it
made it very very simple to visualize what a program was doing
(especially when you turn the speed up fast enough and can see
where the loops are crunching along). The final implementation
of this should be very nice. [Jim Gimple (formerly a Snobol
afficianado from Bell) is doing this work].
2) A high res/color PWB system with joystick and mouse. They are
spending a lot of time working on the "editor language" (which
is also the JCL and workstation control language) rather than
"cutsie" features to add to the user view. The file structure
is Unix based but they ALSO feel that unix's user view is a
total lose and are designing one of their own that, from what
I saw, will be much nicer. Again, their position is that this
will be used by programmers, not managers or secretaries and
they are giving the user power to change things (in a properly
controlled manner) at whim without too much work. Currently
they are having trouble with the Univac hardware research
people (it's too slow for them) but that should be resolved
soon. This project is under control of Marc Fogel and Ira
Ruben.
3) Help systems. Knoweldge based and natural language driven (if
you like) user aids for the station command language etc. They
have several NL and AI people very interested in user assitance.
I don't know how/if this relates to the workstation but it was
interesting none-the-less. This work was being done by Nathan
Relles and Norm Sondheimer (president of the ACL).
All of the above is managed in a very small group of very expert
people by Dick Wexelblat and for more info one can write to
Sperry Univac
Software Research
2G3 Bluebell, Penna.
19424
They are going to have an Apollo and/or a couple of Perqs soon.
-- Jeff
∂26-Jul-81 2028 AVB Xerox announcement on Dolphin/1100
To: "@SUN.DIS[P,DOC]" at SU-AI
Date: 22 Jul 1981 1736-PDT
From: RINDFLEISCH@SUMEX-AIM
Subject: INFORMATION RE INTERLISP DOLPHINS
Ed Feigenbaum received the following message from Mr. R.E. Bomeisler,
Marketing Manager for Xerox EOS, in response to repeated requests for
more information about Dolphins necessary for planning acquisitions.
Since others may be in the same situation, Ed wants to pass the
information along to other computer scientists. You may forward
it if you wish.
Tom R.
*********************************************
7/16/81
"In our telephone discussion, Ed, you indicated that Xerox
was not providing you and potential users with enough information
to assist you in designing your networks and planning for future
growth. I would like to apprise you of the steps we have taken
at XEOS to fill the information gap.
Marcel Pahlavan is the program manager and is the focal
point for responding to customer inquiries on interface and other
technical matters. On August 1, Terry Haney will join the staff
to provide hardware expertise. An Interlisp software expert is
being actively recruited. In addition, Pahlavan can call on other
system experts within XEOS to solve specific customer problems.
With regard to 3M bps Ethernet networks, the 1100 system
includes the hardware necessary for connection. In addition,
XEOS will make available the hardware necessary to connect the
DEC Unibus. This includes the DEC Unibus Ethernet Interface
Board, Transceiver, Terminator and Connector. This hardware
enables connection to 3M bps Ethernet on the DEC PDP-11 family
aswell as the DEC 2020 and the VAX family. To connect the
DEC 2040, 2050, and 2060 to 3M bps Ethernet will require either
development of a Massbus Ethernet Interface Board or a PDP-11
front end interface. When either of these is developed within
the ARPA-sponsored research community, XEOS will facilitate
distribution.
XEOS is a systems organization with the skills to develop
special hardware or software. It is expected that we will be
called upon to modify the 1100 hardware or software to meet
special customer requirements.
With regard to DEC hardware/software, there exists within
the ARPA research community a number of special systems. Many
of these exist on your own campus. As we become familiar with
thesesystems, XEOS will serve as a facilitator and will make
certain that potential 1100 users are familiar with interface
software that exists or is under development. To the best of
our knowledge, the following systems have been or are being
connected to the 3M bps Ethernet: KI-10/TENEX, KL-10/TENEX,
2020/TOPS-20, 2050/2060/TOPS-20, and VAX/UNIX. XEOS will
facilitate distribution of the Stanford-modified PUP software.
As you know, this software runs under TENEX and TOPS-20 and
enables DEC KA-10, KI-10, KL-10, and DEC 2020 to act as file
server to the 1100.
The dissemination and distribution of information would
be greatly enhanced by formation of an 1100 users group. XEOS
is prepared to assist in the organization of such a group.
XEOS plans to make available the necessary hardware and
software to connect the 1100 system to the 10 M bps Ethernet,
thus providing access to the Xerox 8000 Network System. We
are also investigating the feasibility of an internet gateway.
With regard to 1100/Interlisp performance, continual
improvements are being made in the code. The system is five
times faster than it was a year ago and significant further
improvement is expected.
Since the 1100 is a powerful, flexible machine, it can
be expanded in a number of ways: physical memory from 576K
words (1.15 M Bytes) to 768K words (1.54 M Bytes), virtual
address space from 4M to 16M words, and increased local disk
storage capacity. Furthermore, there is sufficient cabinet
space to add special functions that might be needed by certain
customers: floating point arithmetic, color display interface,
image processing, and other special logic, etc. XEOS is inves-
tigating the feasibility of adding to the 1100 system: color
display, low cost bit map display, large capacity file server,
and 5700 electronic printing system. The architecture, I/O
structure, and bandwidth of the 1100 make it the ideal machine
for dedicated applications in the research and scientific
environment.
In addition to Interlisp, XEOS is planning to implement
Smalltalk on the 1100. The schedule is yet to be determined.
As a key ingredient of the overall 1100 program, it is
planned to release a version of Interlisp on the Star processor
after January 1, 1983. This will provide Interlisp to future
users on a very cost-effective basis.
I trust, Ed, that this information will enable you and
others to plan system expansion."
-----
Subject: "mundane" systems
∂26-Jul-81 1553 Jan Walker <JWALKER at BBNA> ''mundane'' systems
Date: Saturday, 25 July 1981 15:59-EDT
From: Jan Walker <JWALKER at BBNA>
To: WorkS at AI
I have to voice my strong support of Joe in his message against
"mundane" systems. The original message advocating mundane
systems used an analogy of a car -- you choose a boring automatic
because you don't care what wonderful things you might be able to
do with a standard transmission. Let's point out a few things
that make this analogy somewhat less applicable to the current
case (system/software design).
Notice that with the kind of technology people are accustomed to,
once you choose one (automatic), you can't have the other
(standard). (This can lead people into defending their choices
with more reasons than they originally had for making the choice.
Some psychologists talk about related phenomena under "cognitive
dissonance".) With the kind of technology we use, you can either
follow the same design philosophy -- make things in a limited
number of flavors and make people choose -- or you can design to
support redesign by the purchaser. Surely with the flexibility
of computers behind us, we can do at least as well as the kludge
in the car that chooses 4, 6, or 8 cylinders depending on load,
mileage goals, or whatever.
People don't like the illusion of choice nearly as much as they
like having the choice. The reason that so far we don't find
ordinary people looking for software modifications is that they
don't expect to be able to have them. (The old technology of
course has molded people's expectations about the new one.)
While I am on the car analogy... I hear a lot about providing
systems for people who want to be able to use a computer without
any training or practice. How many people do you know who wanted
to just jump in and drive a car without any training or practice?
(Not many!) Why do you suppose that difference exists? Consider
that a car has one primary purpose -- transportation. They all
have standard components and operating procedures. Even people
who have never driven know a lot about cars, for example, that
they have a little slot where you put a key and turn it in order
to start the engine. The point is that cars are simpler in
purpose and operation than computers, yet people don't expect to
just hop in and drive away until they know from cars. Maybe the
real lessons in this analogy come from considering training,
learning, and transfer issues.
The ideal way to provide software is to offer something that a
new user who knows about the application of the software (for
example, editing, drawing) can start using it with the help of a
good summary and maybe 15 minutes of explanation. The next
hurdle to pass is in discovering that things can in fact be
changed. A well-designed and documented program helps you make
this discovery and then provides good support tools to help you
find out what it is possible to change and how best to do it.
Jan
(JWalker@BBNA)
Subject: re: REM' s remarks on Global configurations
∂29-Jul-81 0907 Farrell at PARC-MAXC re: REM' s remarks on Global configurations
Date: 27 Jul 1981 11:47 PDT
From: Farrell at PARC-MAXC
To: REM at MIT-MC
cc: WorkS at MIT-AI, Farrell
In places, you simply misunderstood / misstated Bruce Hamilton's
position; in others, your positions are new (and interesting).
Corrections/clarifications:
Bruce demanded 56 Kbaud, not Mbaud. The 3 orders of magnitude
easily cross the frontier of available technology.
There are a number of "centralized" services besides
archiving/library: printing, mail distribution, gateways to other
systems & nets, to name 3. Note also that file storage is a com-
munication mechanism as much as a receptacle -- it is easier (&
more efficient) to store a large object in a commonly accessible
container or two, & pass a pointer, than to ensure direct transfer
from the source to each destination.
Your framework of workstation & centralized facilities is impoverished
(and I believe not justified by Hamilton's discussion): there is no
requirement that facilities be centralized; in particular, there are
good reasons for distributing different services (functions) onto
different servers (machines), and for replicating and distributing
servers geographically (minimize communication, limit loss, provide
convenient user access). Even with most communications involving a
server on at least one end, this distribution still requires high
capacity in the underlying medium. When the net (or whatever) must
also support frequent reconfiguration, you may as well provide that
bandwidth to everyone, so you don't have to decide in advance which
ones are going to be servers.
Probably derived from your workstation/centralized facilities
dichotomy (and maybe a little from Bruce's remarks), I think
you put too much emphasis on network (i.e. communications medium)
failures, when server failures are more of a problem. I derive
this from my experience over 8 years now with two networks, ARPAnet
& 3mb Ethernet. In each, I can recall 1 occasion when I noticed
thenet was down -- that is, that NOBODY could use the net. (I
know the ARPAnet went down regularly for new releases of the IMP
software, and I've heard of outages on both which I didn't happen
to hit. . .) Contrast this to many occasions when I couldn't get
at MACSYMA, or the Datacomputer, or print on Clover, or wasn't
getting my mail, or . . . . Few of us are so single-minded that
we can't work around loss of a server (which needen't even deny
us the service -- e.g. redundant printing/file/mail servers).
Your super-automatic archive to file server has much to recommend
it; two possible drawbacks are that data on my local disk is less
accessible than anything that has hit the net or been stored in
a file server (clearly, holes that should be fixed; but while
they're there . . . ), and such a catholic approach may require
more resources than justified (I suspect workstation time and
file server space are more critical than communications
capacity).
Jerry Farrell
Subject: apollo s/w release 2.0
∂29-Jul-81 0941 Andy.VanDam at CMU-10A apollo s/w release 2.0
Date: 29 July 1981 1028-EDT (Wednesday)
From: Andy.VanDam at CMU-10A
To: works at mit-ai
CC: Andy.VanDam at CMU-10A
Message-Id: <29Jul81 102809 AD50@CMU-10A>
The second release of Apollo DOMAIN s/w happened as promised in
mid-July. Performance has improved greatly - cmd startup time
is (usually) instantaneous, cmds execute much faster (cp, for
example, is about 25% faster both for copying local-local and
over the network), and most known bufs have been fixed. Func-
tionality has also increase (although there's still plenty of
room for more increases...): there are a few new s/w tool cmds
(such as Unix-like sed, grep, macro processor), the display
manager (i.e., their full-screen editor) has cut, paste,
searches, and the user can access the display memory and
bit-mover.
In response to a query from the other week, yes, the Apollo
Users Workshop did take place at Brown on 21-22 June. Users
and potential users from: USAF Geophysics Lab, Bell Labs,
CaslTech, CCA, Computer Techniques, Cornell, Daniel Wagner,
AHarvard, IBM Cambridge, MIT, Mentor Graphics, Schlumberger
Well Services, UMass - Boston, UPenn, and Yale briefly
described what they are planning to do with their apollo's,
Dave Nelson and Bill Poduska talked in detail about the
company's plans for s/w releases and general growth, Kim
McCall from PARC-LRG talked about implementing Smalltalk
on an Apollo, and workshops were held about porting unix,
graphics, lisp, and tex.
The general reaction of the participants was that Apollo is
listening to its user community, which at present is primarily
CS R&D/academia. Apollo looks like it will be around for quite
some time, and will be emphasizing mktg for commericial world
(though they promise not to forget us CSers). Presently, the
h/w is quite solid, and most agree that the s/w is still about
a year away from being there.
Details of Apollo's plans discussed at the mtg are confidential.
Contact me for a list of participants (w/ phone, arpa addreesses)
that can be contacted for more direct info, or for a short (3
sentence) summary of what the participants said they'd be doing
with the Apollos.
Marc Brown
Subject: Mouse Guts
∂29-Jul-81 1023 Eric K. Olson <OLSON at DEC-MARLBORO> Mouse Guts
Date: 28 Jul 1981 0927-EDT
From: Eric K. Olson <OLSON at DEC-MARLBORO>
To: WorkS at MIT-AI
Message-ID: <MS"5(1631)"11747606017.5.545.5372 at DEC-MARLBORO>
Conglomeration of responses to "How does a mouse work?":
Currently, a mouse is a small box with a fairly large (1-2 cm
diam.) ball bearing captivated so a fraction of it lies outside
the bottom of the box. As the box is rolled around, two wheels
positioned perpendicular to one another pick off the rotational
motion of the ball in their plane only (they slip in all other
planes). Hence we get two rotational motions, one for each
component of the two-dimensional motion of the mouse.
The direction and (over time) speed of the rotation shafts are
measured by disks attached to the shafts encoded with a gray
code, and read either photoelectrically (via led and phototran-
sistor) or mechanically (via brushes). The grey code output
might look like 00 01 11 10 00 going one way and 00 10 11 01 00
going the other, so we can tell the difference in direction.
Some historical information about mice, according to Bill Barns:
The mouse as originally invented by Doug Engelbart and Bill
English and patented by them (rights assigned to their employer
at the time, Stanford Research Institute (now SRI International))
consists of two high precision potentiometers connected mechan-
ically to metal wheels with rather sharp edges, approximately 2
inches in diameter, and set at right angles to each other as close
as possible without touching. [This seems a kludgey way to get
this motion, because the pots would "pin" occasionally, even if
they were 20-or-more-turn.] The pots are mounted on a metal base
plate to which is attached a bracket. On the bracket there are
(in the original, and still popular configuration) three switches
which are triggered by buttons about 5/16 inch diameter [8 mm]
which rest upon spring metal fingers attached also to the bracket.
The bottom of the metal finger rests on the momentary-contact
actuator of the microswitch. This arrangement puts some "click"
into the feel. The switches typically are SPST with a common
ground so that for a three button mouse there are four wires for
the switches and one wire for the non-ground side of each pot - 6
total. The mouse wheel voltages are fed into an analog->digital
converter of about 10 to 12 bit resolution and at appropriate
times, some logic samples the digital value and does the
appropriate thing.
Engelbart lives on at Tymshare, and English went to Xerox PARC
and gave birth to Alto etc., (not sure if he's still there).
Bill estimates the invention of the mouse between 1962 and 1967,
and *guesses* 1963/4.
By the way, I got several warnings about suits, patents that I
musn't breach, etc, which I condense below:
Patents to SRI and Xerox apply to a number of features of the
design. The Englebart/English Patent is probably still in
force, and it covers both digital and analog mice. [I was
warned to check the patents before building my own. I really
don't think that building your own personal whatever falls
under patent laws (unless possibly if you sell it).]
Thanks to Jerry Farrell (Farrell at PARC-MAXC), Bill Barns
(Barns at OFFICE), Craig Everhart (Craig Everhart at CMU-10A),
and Steven Kirsck (SK at MIT-MC).
-----
Subject: Big AND Small
∂31-Jul-81 0459 Rivanciw at Darcom-HQ Big AND Small
Date: 30 Jul 81 8:37:19-EDT (Thu)
From: Rivanciw at Darcom-HQ
To: works at Mit-Ai
Via: Darcom-HQ; 30 Jul 81 8:49-EDT
In reading the debates pro and con on big systems and little
systems, where big systems are large mainframes and little
systems are personal workstations it seems that the best of
both worlds would be architectures for office automation that
encompass both. Let me illustrate how we have attempted to
incorporate both worlds in our OA plans.
DARCOM has a DEC 10 (DARCOM-KA) on the ARPANET which it uses
to provide electronic mail and other OA services to a broad
community of users throughout the command (the command is all
over this country). Access is via ARPANET. Advantages here
are that for a relatively inexpensive yearly charge a remotely
located single user can obtain OA service with a communications
capability as powerful as the ARPANET. This service is in such
demand that we cannot supply services in large enough quantities
(thus the DEC 10 will soon be replaced with a couple of 11/780s
to provide more services).
One level down (in computer size) DARCOM uses what it calls
LARGE CLUSTER machines. These are mini computers (DEC 11/70
size) which provide LOCAL OA services to 100-150 users. Long-
haul communications is accomplished via the RELAY computer
to the ARPANET (or dial-up communication channel to non-ARPA
computers). These Large Clusters are not hosts on the ARPANET.
The computer I am working on right now is one of these large
clusters. This message is routed to the RELAY computer which
routes it to the ARPANET for delivery.
The next level down SMALL CLUSTER. The small cluster is a
general purpose micro computer (like the ONYX or "C" Machine).
The Small Cluster services 8-30 users. It communicates with
the LARGE CLUSTER for large file storage and backup. Communi-
cations on the small cluster are handled via the large cluster
or the RELAY.
The lowest level is the personal workstation (one user). We
haven't gotten there yet in large scale implementation. Yes,
we have a lot of personal workstations around but have not
yet incorporated them into our large scale implementation
plans yet.
This architecture is used for economies of scale and incremental
investment on behalf of the user. For example, let me paint
a typical scenario of one of DARCOM's subordinate commands or
activities just entering into the world of office automation:
The Commander or somebody at the command wants to try office
automation. Now they are unsure of its benefits so they don't
want to spend mucho money. The buy a mailbox on our DARCOM-KA
(LARGE MAINFRAME). With this mailbox they can experiment with
all the OA tools.
After a short while they want 5 or 10 other people at
their command or activity to get mailboxes so that they can
communicate via electronic mail. They buy more mailboxes
on the large mainframe.
Then it is determined that office automation is good for the
command. They make large scale plans to provide OA services to
100, or 200, or 300, or how-ever-many prople. At this point the
economies of scale move towards the LARGE CLUSTER machine. With
a large cluster installed locally, the command is essentially
running their own OA.
But soon they find that more and more users are demanding service.
Enter the small cluster. As one division goes from one or two
users (who were getting OA services on the large cluster) to a
demand to provide services to 8 or 10 people in that particular
division, a micro computer is installed in the division to provide
those services (and offset the demand on the large cluster). An
example of this implementation is DARCOM Headquarters. We began
by buying accounts on the big DARCOM-KA (large mainframe). When
demand grew to 60 users we brought a large cluster into the
building. The number of users on the large cluster grew from 60
last Oct to 210 as of last week. We now have some 20 micros on
order. These micros will service 8-10 user each so we now supply
services to an additional 160-200 individuals. As folks move
off the large cluster to the small cluster there are more folks
wainting in line behind them for accounts on the large cluster.
This multi-level (of size?) architecture seems to be working
pretty well for providing services to our command.
Randy
Subject: Keystroke Monitoring
∂31-Jul-81 0721 Eric K. Olson <OLSON at DEC-MARLBORO> Keystroke Monitoring
Date: 30 Jul 1981 0128-EDT
From: Eric K. Olson <OLSON at DEC-MARLBORO>
To: TAW at SU-AI
cc: WorkS at MIT-AI
Message-ID: <MS"5(1631)"11748043074.24.545.10627 at DEC-MARLBORO>
As I said in a message to Human-Nets (once again, the two lists are
discussing similar things), I think a reasonably valid statistic
for keystroke monitors indicating performance of the secretary is
keystrokes per character in output document. This way the typist
that makes no errors will have fewer keystrokes (lower, better
score) than the typist that makes lots of errors to produce the
same document. This also takes care of the problem of a secretary
idling by typing jkl;jkl;jkl;jkl;jkl;. I personally do not condone
the use of keystroke monitors to monitor performance (I think that
management should not even be told the statistic is available).
This all assumes of course that the monitor is on a word processing
system used primarily for word processing. Programmers shouldn't
be subjected to keystroke monitors (I am a little more vehement
about this; it hits home), and fortunately the statistic is harder
to generate for programmers.
-Eric
-----
Subject: WorkS Digest V1 #1
∂03-Aug-81 0629 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #1
Date: 3 AUG 1981 0849-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Mon, 3 Aug 1981 Volume 1 : Issue 1
Today's Topics:
Administrivia - Welcome, Workstations - Harvard Apollo Experience,
Polls - OA System Developers & WorkS Census
----------------------------------------------------------------------
Date: 1 Aug 1981 (Saturday) 0956-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: Administrivia - Welcome to the WorkS Digest
To All WorkS readers:
As you have probably guessed, we are making the workstation
discussion list into a digest. It shall be a daily digest.
One of the few things we are looking for is a moderator. If
you have the (a) interest, (b) the time, (c) easy and proper
access to the Network (MIT computers), and (d) the patience,
please drop a message in WORKS-REQUEST@MIT-AI.
Henry Dreifus
------------------------------
Date: 2 Aug 1981 (Sunday) 1422-EST
From: BUSH at HARV-10
Subject: Four Months with Two Apollos
We have had two Apollos at Harvard for about four months
now, and I have a few personal observations to contribute from
my experience with them.
The best way to describe them is as a state-of-the-art
product, with the emphasis on product. The Apollo seems to be
the best large-micro-based system available with a bit-mapped
display, Winchester disk, and high-speed local network. Since
it started a little over a year ago Apollo Computer has managed
to produce a very solid piece of hardware, and quite a bit of
software. We have had no trouble with the hardware, and the
software, while poorly documented and a tad flakey (we are a
beta test site), has been basically usable. The network file
system works, and, on our small network, file access is not
appreciably slower for remote files.
The Apollo is not, however, a state-of-the-art tool for
computer science research, nor does it claim to be. It is not
a Dorado nor a Star-with-Mesa. A lot of the folks at Apollo
came from Pr1me, and in order to produce a working, competitive
product, they built what they knew how to build for a market
they were familiar with (the engineering/scientific market).
The system was tuned for user programming in FORTRAN, not system
programming, with such things as interprocess communication and
software interrupts not supported. Now that its primary market
is academic, Apollo will put a number of these features in, but
system programming, and the kind of features it requires, are not
a fundamental target of the system software. The system also has
a rather unsophisticated human user interface. Some of this is
clearly a matter of time, but some things that I imagine people
at Xerox would consider basic, such as a mouse and non-confusing
windows, are not along yet. (The Apollo windows are confusing
because they are all full-screen width and bordered with a single
line, so it is difficult to determine which windows are on top.)
It seems that Apollo did not do a lot of research in designing
their product, but instead will be educated by their users.
Bill Bush
------------------------------
Date: 2 August 1981 11:34-EDT
From: Brian P. Lloyd <LLOYD at MIT-AI>
Subject: Results of Poll
Here are the results of the "Are you actively working on an
Office Automation system" poll. The results surprised me very
much. Here are some of the numbers:
Responses 32
Working on a system 23
Not working 9
The "Not Working" column also contains responses from people
indicating that they were simply implementing OA functionality
on their home systems (e.g. not for commercial sale/distribution).
That was a value judgement on my part and may not be valid.
There were many very interesting responses but in order to keep
this message short I will exclude most. Two immediately caught
my eye and are reproduced here:
------------------------------
Date: 18 Jul 1981 13:22 PDT
From: XXXXX at PARC-MAXC
...
The Xerox redistribution list for WorkS currently contains
57 members. I don't know exactly how many of them (us) are
actually working on workstation design or implementation,
but I suspect about 75-80% are, in one capacity or another.
-- XXX
------------------------------
Date: 16 Jul 1981 21:05 PDT
From: Kimball at PARC-MAXC
Nearly everyone from Xerox on list, as you surmised...
Ralph Kimball
Manager CUSP Development, Xerox
------------------------------
In the first note I was asked not to reveal the sender. Based
on the numbers in the first message, we could probably skew
the results, but that is up to you.
As mentioned earlier, the raw responses are in the file
USERS3;LLOYD WORKS on the MIT-AI machine.
Brian
P.S. I too am actively working on a system. I am managing the
software development for the M/A-Com Executive Management
System (MEMS) which uses the Convergent Technologies
hardware.
B
------------------------------
Date: 3 August 1981 08:00-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
Subject: WorkS Census II
On 25 June, Randy Rivanciw proposed a census to give everyone
who wished, a chance to briefly describe who they are and what
their professional interest in personal workstations is. We
already have a variety of responses. However, a large number
of people have been added to the list since 25 June. Now that
the list population has stabilized, we want to give everyone a
chance to participate before making the results available.
If you would like to participate in this census and have not
already responded, please forward a brief description of your
interests in personal workstations to WORKS-CENSUS@MIT-AI.
Please do so promptly however, as we will make the results
available early next week.
Enjoy,
Roger
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #3
∂09-Aug-81 1202 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #3
Date: 9 AUG 1981 1418-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Sun, 9 Aug 1981 Volume 1 : Issue 3
Today's Topics:
Query - Smalltalk
----------------------------------------------------------------------
Date: 6 Aug 1981 1002-EDT
From: Bob Hyman <HYMAN at DEC-MARLBORO>
Subject: Smalltalk systems
What-all systems support smalltalk? Are there dialects of
smalltalk, as there are of FORTH? Do smalltalk systems come
without the graphics-oriented user interface?
Bob
------------------------------
Date: 9 August 1981 12:00-EDT
From: "The Moderator" <Duffey at MIT-AI>
Subject: Archived information about Smalltalk
Smalltalk has come up briefly in several earlier WorkS discussions.
For your convenience, a summary transcript of the archived material
on Smalltalk is included below. Complete copies of these messages
are available upon request from the archives.
-- RDD
... LRG, a group within PARC, has licensed Smalltalk-80 (the
only Xerox-authorized version of Smalltalk to be released)
to a number of micro- and mini-computer manufacturers. The
release consists of detailed specifications for the machine-
dependent kernel, plus a mag tape containing the rest of the
system (windows, editor, compiler, file system, etc., etc.)
Several of these manufacturers have made excellent progress
on implementing the system, to the point of having windows
appear on their displays. I can't comment on the specific
list of manufacturers, since we prefer to let them make
their own announcements. ... and we are currently working
out ways to license the system to manufacturers (and univer-
sities) beyond the original group. I can't comment on the
availability of Smalltalk for the Star, except to say that
the Star hardware is definitely powerful enough to support
Smalltalk.
-- <Deutsch at PARC-MAXC>
Smalltalk IS being released by PARC this summer. There
was a big presentation on the subject at this year's NCC.
Apple, DEC, HP and other companies are doing research
into implementing it on their machines. (In fact, one of
the primary Smalltalk implementors, Larry Tesler, is now
at Apple and was one of the speakers at NCC.) A huge
article on the subject will appear in the August issue
of BYTE.
The deal is that PARC gives you an "image" file on a
tape, which contains all of Smalltalk ready to run. To
run it, you have to implement an interpreter on your
machine for the 256 Smalltalk bytecodes. Just like you
can run Pascal, if you have a P-code interpreter.
-- Ron Newman <NEWMAN.ES@PARC-MAXC>
... Xerox intends to release a book on Smalltalk called
Smalltalk 80. This version of Smalltalk is intended to be
easily portable. There was some discussion within Xerox
legal about whether the Smalltalk virtual image would be
released. But the book which describes the interpreter
plus the virtual image would result in a very easily
portable language.
One could then port it to the machine of your choice,
including the STAR, assuming that you could PROGRAM
the STAR. When MESA gets released you will be able to
implement it in that: but a better place is microcode.
I haven't heard anything definitive about whether Xerox
intends to microcode the Dandelion (STAR workstation)
for Smalltalk.
-- Michael <mike at RAND-UNIX>
... Also, XEROX is now putting up Smalltalk on the Star,
for internal use. I have no idea, and I suppose neither
does XEROX, if they'll ever release it.
-- Chris Ryland <RYLAND at SRI-KL>
Ed Feigenbaum received the following message from Mr. R.E.
Bomeisler, Marketing Manager for Xerox EOS, in response
to repeated requests for more information about Dolphins
necessary for planning acquisitions. ...
*********************************************
"In our telephone discussion, Ed, you indicated that
Xerox was not providing you and potential users with
enough information to assist you in designing your
networks and planning for future growth. I would like
to apprise you of the steps we have taken at XEOS to
fill the information gap.
...
With regard to 1100/Interlisp performance, continual
improvements are being made in the code. The system
is five times faster than it was a year ago and signi-
ficant further improvement is expected.
...
In addition to Interlisp, XEOS is planning to
implement Smalltalk on the 1100. The schedule is
yet to be determined.
As a key ingredient of the overall 1100 program,
it is planned to release a version of Interlisp on
the Star processor after January 1, 1983. This will
provide Interlisp to future users on a very cost-
effective basis.
...
********************************************
-- Tom R. <RINDFLEISCH@SUMEX-AIM>,
forwarded to WorkS by <Geoff at SRI-CSL>
In response to a query from the other week, yes, the
Apollo Users Workshop did take place at Brown on 21-22
June. Users and potential users ... briefly described
what they are planning to do with their apollo's, Dave
Nelson and Bill Poduska talked in detail about the
company's plans for s/w releases and general growth,
Kim McCall from PARC-LRG talked about implementing
Smalltalk on an Apollo, and workshops were held about
porting unix, graphics, lisp, and tex. ...
Details of Apollo's plans discussed at the mtg are
confidential. Contact me for a list of participants
(w/phone, arpa addresses) that can be contacted for
more direct info, or for a short (3 sentence) summary
of what the participants said they'd be doing with
the Apollos.
-- Marc Brown in care of <Andy.VanDam at CMU-10A>
The August issue of BYTE is devoted to Smalltalk. The
good folks at Xerox PARC contributed quite a bit to the
issue. I'll refrain from further comment till I've read
the thing.
-- <decvax!duke!unc!smb at Berkeley>
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #4
∂12-Aug-81 0247 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #4
Date: 12 AUG 1981 0522-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Wed, 12 Aug 1981 Volume 1 : Issue 4
Today's Topics:
Query - Micro benchmarks, Reply - Smalltalk
----------------------------------------------------------------------
Date: 11 Aug 1981 1917-PDT
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: Micro Benchmarks
Has anyone performed, or seen documentation concerning,
benchmark comparisons of micros commonly used in
workstations/personal computers? Specifically, the Z80,
8086, M68000, LSI-11/2, LSI-11/23. Please send replies
directly to me and I will compile the results and submit
to works. Thanks. -Steve
------------------------------
Date: 11 Aug 1981 08:41 PDT
From: Adele at PARC-MAXC
Subject: Xerox Smalltalk
Various messages have been sent on this distribution list
relative to the release of the Xerox Smalltalk-80 (tm) system.
The messages in general are inaccurate or not complete because
plans for general distribution are not yet set. At this time,
for individuals to obtain information relative to their own
needs, you can contact me directly via telephone or
non-electronic mail.
Adele Goldberg
Xerox PARC
Learning Research Group
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #5
∂13-Aug-81 0624 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #5
Date: 13 AUG 1981 0740-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Thu, 13 Aug 1981 Volume 1 : Issue 5
Today's Topics:
Reply - Micro Benchmarks, FYI - IBM's Personal Computer
----------------------------------------------------------------------
Date: 12 Aug 1981 2246-PDT
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: Micro Benchmarks Results
Many thanks to those who responded to the micro benchmark query.
I have summarized the benchmarks reported in the April 1/81 issue
of EDN, but the article should be read for details concerning the
benchmarks. It appears that the 68000 is the hands down winner,
unless you need floating point processing and can't wait for the
chip (floating point benchmarks were not performed in the report).
I have appended messages (edited to remove redundancy) from those
who responded to the query.
Benchmark tests were compiled at CMU in 1976, and coded by each
manufacturer.
MICRO | LSI-11/23 | 8086 | 68000 | Z8000 |
-------------+------------+-------------+-------------+-------------+
BENCHMARK | Code| Time | Code| Time | Code| Time | Code| Time |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
I/O Interrupt| 20 | 114 | 55 | 126 | 24 | 33 | 18 | 42 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
I/O w/FIFO | 86 | 1196 | 85 | 348 | 118 | 390 | 106 | 436 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Char. Search | 76 | 996 | 70 | 193 | 44 | 244 | 66 | 237 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Bit Ops | 70 | 799 | 46 | 122 | 36 | 70 | 44 | 123 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Linked List | 138 | 592 | 94 | - | 106 | 153 | 96 | 237 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Quicksort | - | - | 347 |1.2E↑5 | 266 |3.3E↑4 | 386 |1.2E↑5 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Bit Matrix | 152 | 1517 | 88 | 820 | 74 | 368 | 110 | 646 |
-------------+-----+------+-----+-------+-----+-------+-----+-------+
Clock time: LSI-11/23 = 3.3 MHz
8086 = 10.0 MHz
68000 = 10.0 MHz
Z8000 = 6.0 MHz
----------------------------------------------------------------------
From: Frank J. Wancho <FJW at MIT-MC>
Subject: Micro Benchmarks
ComputerWorld has been running a series of benchmark articles
over the last six months or more and periodically publish
accumulated summaries of the results in each category.
--Frank
----------------------------------------------------------------------
From: Nowicki at PARC-MAXC
Subject: Re: WorkS Digest V1 #4
Forest Baskett has the famous "Baskett Benchmark" that has been
run on machines like Dorados, Dolphins, Altos, 10s, 20s, Vaxen,
and MC68000 in both C, "hacked" C and Pascal. The results
are very informative. I would like to see the results on other
microcomputers. By the way, we get almost 40% VAX/780 performance
on the 8 MHz 68000 in this test, which is a small, integer only,
compute bound puzzle solver.
-- Bill
----------------------------------------------------------------------
From: CAIN at SRI-AI
Subject: Micro benchmarks
The April 1, 1981 issue of EDN has a number of benchmarks
between the LSI-11/23, the 68000, the Z8000, and the 8086.
They are taken from a more complete study done at CMU which
I was hoping to find one of these days.
Since these benchmarks omitted floating point tests, I
performed a couple informal ones on a 68000 with Doug Beck
here at SRI. To do 10000 iterations of a floating point add,
subtract, multiply, and divide took 71 seconds (implying 1.75
milliseconds per operation) using Whitesmith's C compiler and
104 seconds using Motorola's PASCAL compiler.
When talking to Motorola about this sluggish performance,
they mentioned that the 68000 has a fast floating point PROM
in development which has done floating-point multiplications
(in software!) in 35 micro seconds. This compares very well
with the LSI-11/23's floating point hardware times.
Also C makes all floating point numbers to double precision
before doing the implied operation, meaning much of that 71
seconds was devoted in going "float-to-double" and
"double-to-float". According to my calculations, the 68000
is capable of that 35 microsecond time easily (roughly 100
to 150 clock states would be required), and since it has the
most support (cross compilers on the VAX, etc), I think it is
the preferable chip. It is promised that the floating-point
support will be built onto the chip mask so that some new
instructions will manipulate floating point numbers directly.
I am seriously weighing the choice of VAX vs 68000 for a new
project (where cost may outweigh the greater power of the VAX).
... Ron
----------------------------------------------------------------------
------------------------------
Date: 12 Aug 1981 2130-PDT
From: Charles B. Weinstock <Weinstock at SRI-KL>
Subject: New IBM Personal Computer
Business Day : IBM Personal Computer
By ANDREW POLLACK
c. 1981 N.Y. Times News Service
NEW YORK - The International Business Machines Corp., the
giant of the computer industry, is thinking smaller: Wednesday
it introduced a personal desk-top computer for use at home,
in schools and in business.
Although the announcement had been expected for months,
it still sent reverberations through the industry.
Besides representing a dramatic change in image for IBM and
marking its entry into consumer electronics, the endorsement
of personal machines by a company whose name is practically
synonymous with computers is expected to stimulate the growth
of the business.
And IBM could pose the stiffest challenge yet to Apple
Computer Inc. and the Tandy Corp.'s Radio Shack division,
the current leading vendors.
"It's one of the most important announcements we've seen
in the industry," said Christopher Morgan, editor in chief of
Byte, a personal computer magazine.
"People will now know that personal computers are not a fad
or a flash in the pan," said Michael McConnell, executive vice
president of Computerland, a chain of a retail stores that will
market the new IBM products.
The price of the machines will range from $1,565, for a
simple system that will require users to provide their own
television screens and cassette tapes, to more than $6,000 for
the most elaborate versions. In addition to Computerland, the
line will be sold through several new business-machine stores
being started by Sears, Roebuck & Co., by IBM's own three retail
stores and directly by IBM to large corporations.
By most accounts of analysts and others connected with
the personal computer business, IBM's machine is impressive
technologically, not because of any single breakthrough, but
because of a combination of good features and sound engineering.
The new model uses a microprocessor capable of handling
16 bits of information at a time, which will permit the machine
to handle data more quickly and perform more complex tasks than
most other personal computers, which have 8-bit microprocessors.
The machine, depending on the model, can store 16,000 to more
that 260,000 characters in its memory.
But analysts disagreed on whether the price would be low
enough to knock Apple or Tandy out of the ring.
In Fort Worth, Garland P. Asher, chief of financial planning
for Tandy, said he was relieved in two ways. "I'm relieved that
whatever they were going to do, they finally did it," he said.
"I'm certainly relieved at the pricing. They haven't introduced
anything that's going to rewrite the ground rules."
Comparing prices is difficult, however, because the machines
come in different configurations and are not directly comparable.
McConnell, of Computerland, which sells both Apple machines and
the IBM home computer, said that in some typical configurations
the IBM machine was several hundred dollars more expensive than
the Apple II, Apple's popular brand. Yet the IBM device is
slightly less expensive than a typical configuration of the
newer, more powerful Apple III.
Other factors such as the availability of programs for the
computer and marketing are equally important, analysts said. IBM
will have fewer retail outlets and fewer programs initially than
Apple and Radio Shack. Yet, Aaron Goldberg, an analyst with the
International Data Corp., a Framingham, Mass., consulting firm,
said IBM's direct sales staff could be a potent force in selling
to leading industrial companies, who might buy dozens of desk-top
computers at a time.
Chances are, there will be room for all the companies, many
analysts believe. The personal computer market is growing
explosively, although accurate figures are hard to get because
there is no clear distinction between home computers, personal
computers for other users and desk-top computers designed for
business use.
International Data estimates that 327,000 desk-top computers,
ranging in price from several hundred dollars to $20,000, were
sold in the United States in 1980, and projects that this total
will increase to 1.3 million by 1985. In dollar volume, the
market is expected to grow from $2.4 billion last year to $9
billion in1985.
According to estimates by International Data and others,
there are approximately a million personal computers in use,
with the largest application being for business and professional
uses. The home and education markets are still small, but are
expected to explode.
When the new computer becomes available in October, the
program offerings will include Visicalc, a popular business
forecasting program; three business and accounting packages
by Peachtree Software; Easywriter, a word-processing package,
and Microsoft Adventure, a fantasy game. The software,
however, will sell in some cases for about twice the price
of the equivalent programs sold for use on other machines.
IBM is also allowing anyone else who wants to do so to
write programs for the IBM machine, which the company would
evaluate. If the programs were accepted for marketing, the
writer would be paid a royalty on sales of the program.
A veritable cottage industry of computer buffs has sprung
up to write programs for other personal computers, and the
abundance of such home-grown programs is largely responsible
for the market strength of the Apple and Tandy computers.
IBM also said it would make its computers nearly compatible
with some other home computers, so programs written for those
machines could be transferred to the IBM model.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #6
∂14-Aug-81 1101 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #6
Date: 14 AUG 1981 1025-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Fri, 14 Aug 1981 Volume 4 : Issue 6
Today's Topics:
Workstations - IBM's Personal Computer, Micro Benchmarks
----------------------------------------------------------------------
Date: 13 Aug 1981 1159-EDT
From: Willie Lim <WLIM at MIT-XX>
Subject: IBM Personal Computer
IBM announced its new 8080 based personal computer yesterday.
The prices range from $1500 to $6000 (approx.). It seems
that the system has color graphics. Does anyone has any
more details on the system? What is the OS on the system
and what are options?
Willie
------------------------------
Date: 13 Aug 1981 0813-PDT
From: Stevan Milunovic <Milunovic at SRI-KL>
Subject: Micro Benchmark Units
The units in the benchmark chart sent Aug 12 were bytes for
code, and microseconds for execution time. Sorry for the
omission. -Steve
------------------------------
Date: 14 Aug 1981 0448-PDT
From: SCHIFFMAN at SRI-KL
Subject: Benchmarking new Micros
I forget where I first heard it said that benchmarking was Advanced
Lying With Statistics....
I looked rather carefully at the EDN benchmarks when they first
came out. I took these more seriously than usual because:
They were in Assembly language; therefore they measure
programmer skill plus machine performance, as opposed to
higher-level-language benchmarks which measure programmer
skill plus machine performance plus compiler quality.
(Worse yet are benchmarks written in different languages
for different machines which throw "language- quality"
into the mix... or benchmarks running on time-sharing
systems that end up measuring scheduler fairness and
disk performance.)
They were written by employees of the respective manu-
facturers who were likely to be skilled with the given
architecture. This also removes the possibility of
unfair advantage given due to hidden prejudices.
A reasonable coverage of routine types were made that
collectively might represent "general performance".
(Including interrupt service routines was a good move,
for example.)
Nevertheless, the benchmarks were about as useless as benchmarks
usually are!
To pick some specific nits--
Although there was ONE environmental parameter supplied (the
clock speed for the given processor) there was no mention of
what memory performance is required to run at that speed
without wait states. I believe it is the case that a 10Mhz
8086 can run with memory much slower (and therefore cheaper)
than a 10MHz 68000. Nor is it mentioned what the availability
of the part is at that clock rate. Did you know that a 10MHz
8086 is $200 cheaper than a 10Mhz 68000? Maybe if you paid
that kind of money to Intel they would sell you a 16MHz part!
The benchmark specifications had loopholes in them which
were taken (quite understandably) to differing advantage.
For example (as best as I can remember) the interrupt
service benchmark did not specify that context had to be
completely saved. The Intel programmers went ahead and
saved all registers anyway (a reasonable thing for a
service routine to do). The programmers for the other
machines only saved the minimal context necessary to meet
the specification.
So much for GOOD benchmarks!
Any yet one often hears that "CPU X is 20% faster than CPU Y"
based on even less careful comparisons.
{BTW, I'm planning to use the 68000 in my next system. And
I do think that is much faster than the 8086 for the things
I want to do. But it's very likely a bit slower (for what
I want) than the Z8000. Don't forget that there are other
reasons for choosing a CPU than how fast it goes.}
Most CPU designers, when pressed, will agree that there is no
reasonable way to collect a small set of general metrics that
will characterize machine performance. To find the fastest
among several computers "in the same performance class" can
only be done by carefully attempting to model the application
for which the machine is to be used. If you are lucky, this
can be as simple as designing your program and coding the
inner loops for each machine to be considered. If you're not
so lucky, you might spend a year building a workload simulator
and still not know how different things will be if you get a
different disk controller.
Doing it right, of course, can be very hard. It's much easier
to refer to a list of how long a quicksort of 100 items takes
for every machine ever invented.
Joseph Weisenbaum (in "Computer Power and Human Reason") tells of
the story about the drunk repeatedly walking around a lamp post
at night. A passing policeman asks him for an explanation. The
drunk replies that he lost his keys--
Cop: "Oh, so you lost them under the lamp post?"
Drunk: "Naw, lost 'em over there." (Waving at the distant
darkness).
Cop: "So why look for them under the lamp?"
Drunk: "Silly! 'Cause the light's so much better here!"
-Allan
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #7
15-Aug-81 1143 DUFFEY at MIT-ML (Roger D. Duffey, II) WorkS Digest V1 #7
Date: 15 AUG 1981 1355-EDT
From: DUFFEY at MIT-ML (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Sat, 15 Aug 1981 Volume 1 : Issue 7
Today's Topics:
Micro Benchmarks
----------------------------------------------------------------------
Date: 14 Aug 1981 15:28 EDT
From: Marshall.WBST at PARC-MAXC
Subject: Micro Benchmarks
A salesman from Intel was here this week and said that EDN has
retracted its benchmarks and will run another set. He said that
the new numbers show the 8086 only 10-15% slower than the 68000.
He said the retraction would be in the next issue.
Sidney Marshall - Rochester N.Y.
------------------------------
Date: 14 Aug 1981 11:36 PDT
From: Kosower at PARC-MAXC
Subject: Re: Benchmarking new Micros
Worse yet, benchmarks can be doubly deceiving, since they
may induce you to choose a micro for all the wrong reasons.
Unless you have a very specific application in mind, or
unless you plan to design and build your own operating system
from scratch, software development facilities, system quality,
and especially user interface quality are extremely important.
A Dorado, for example, may run faster than greased lightning,
but it would be about as useful as an F-15 powered by turboprop
engines if it had IBM-quality software running on it. After
all, most of us do not want to write reams and reams of code
in some J-random processor's assembly language (more so if it's
microcodable); so quality of the high-level language available
and quality of the compiler ARE important. Furthermore, most
applications change, and even with changes, their lifetime is
limited, so that other development facilities (editor, debugger,
etc.) are ALSO important. If it takes you 10 times longer to
write a program that will take 10 times longer to debug and will
eventually run 10 times slower, on processor A whose raw speed
is 10 times greater than that of processor B, which one would
you choose? Choosing B will save you time, to say nothing of
frustration, even though it is a "slower" processor. These are
not idle thoughts: an IBM 370/168 has tremendous raw speed, but
some of the cruftiest software ever written makes it seem slower
than the US Postal Service. Admittedly, almost all of the
software for micros such as the 8086 and 68000 is pretty awful,
but I still think it's worth keeping the above considerations
in mind. As Allan points out, just because something is easy
to measure does not mean it's useful or even meaningful.
David A. Kosower
------------------------------
Date: 14 August 1981 1832-EDT (Friday)
From: David.Lamb at CMU-10A
Subject: EDN benchmarks
Allan Schiffman may be right that the EDN benchmarks are
"about as useless as benchmarks usually are," but the MCF
(Military Computer Family) test specifications on which
they were supposed to be based *can* be used in a sensible
fashion to evaluate a computer architecture. The original
experiment design was set up at CMU with the co-operation
of one of the members of out Statistics department, who
designed the experiment to separate variance on the tests
into differences based on programmers, particular tests,
and the architecture itself. The notion was to see how
good the *architecture* (instruction set, visible registers,
etc.) was, rather than any particular implementation of the
architecture. Several different measurement scales were
set up. One measured the number of bytes need to encode
the programs, another measured the memory accesses needed
in an idealized implementation, and the third measured the
amount of data transferred between registers in the idealized
implementation. I'm a little disappointed that the tests are
being used now for a different purpose; it's not clear to me
that you want the same kinds of tests to do a comparison of
particular implementations of the architecture, as was the
case in the EDN tests.
------------------------------
End of WorkS Digest
*******************
Subject: WorkS Digest V1 #8
∂18-Aug-81 0804 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #8
Date: 18 AUG 1981 0811-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
To: WorkS at MIT-AI
WorkS Digest Tue, 18 Aug 1981 Volume 1 : Issue 8
Today's Topics:
Workstations - IBM's Personal Computer, Micro Benchmarks
----------------------------------------------------------------------
Date: 17 Aug 1981 1331-PDT
From: Rubin at SRI-KL
Subject: IBM Personal Computer
For those of you who stay in touch by computer rather than paper
or radio: Here's the latest on the IBM PC. It's a three-piece
unit, VERY slim nice-looking keyboard, with basically the same
key layout as the 5250 series. The display looks cosmetically
the same as a displaywriter's, and sits on a logic box with dual
diskettes. Inside we have an 8088, up to 256K, five expansion
slots, 80x25 screen memory with graphics 320x200 or 640x200.
Figure it out, that means an OK but not great 8x8 character
cell. The unit displays up to 16 foreground colors on 8 back-
ground colors (but I doubt if all those are available in the
graphics modes). And you get a sound generator and built-in
speaker to boot!
The thing is totally modular; even the I/O cards are separate!
For $ 1,565 you get a keyboard and logic unit with 16K RAM and
a Basic interpreter in 40K ROM. A cassette interface is built
in, I think; but no diskette or monitor at this price -- you
use your TV set. Of course you can add one or two minidiskettes,
lots more memory (16-64k increments), a B&W monitor (no color
monitor was mentioned), RS-232C interface card, matrix printer,
a joystick/paddle interface (but you have to buy somebody else's
joysticks and paddles); and maybe the kitchen sink. A "business
configuration" with 64K, dual diskettes, printer, and "color
graphics" goes for about $ 4,500.
The big news might be the software -- there's plenty of
it. If you don't like their idea of a diskette OS or Pascal
compiler or word processor, you can try USCD Pascal or CPM-86,
coming soon from Softech and Digital Research. (Gee, and I
was looking forward to JCL). And then there's Visicalc, three
Peachtree business applications, Microsoft Adventure, 3270
emulation on the way, and a new IBM Software Publishing outfit
(!**8). It looks like they read Byte.
Where can you get it or ogle at it? Try your local Sears,
Computerland, or IBM store (or DPD sales rep, if you're a
big banana).
Darryl Rubin
SRI International
------------------------------
Date: 17 Aug 1981 1220-PDT
From: Rubin at SRI-KL
Subject: Micro benchmarks
This may sound like an answer that begs the question. But THE
one true way to benchmark a micro depends entirely on your point
of view. (As you see, I have an unmatched knack for discovering
the obvious.) CPU architecture and instruction throughput matter
the most to designers of CPU boards for number-crunching and other
compute-bound stuff. Good I/O architecture and throughput score
highest to OEMers of communications and data base boxes. Good
compilers, spiffy user interfaces, and software tools (Xerox we
hear you!) matter the most to the rest of us system developers
and end users. What you will "see" is what you should measure.
Just to be exhaustive if not obsessive, I'll mention the sometimes
overlooked importance of good I/O controllers and peripherals,
especially big fast disk; a W-I-D-E choice of hardware and
software offerings; reliability, support, and the prospects for
compatible future enhancement. Most of all, vendor credibility
and track record. How do I benchmark thee, have I counted all
the ways?. . .
Darryl Rubin
SRI International
------------------------------
Date: 15 AUG 1981 1411-PDT
From: STEWART at PARC-MAXC
Subject: Benchmarks
Quote from ???: "There are lies; there are damn lies;
and there are benchmarks."
-Larry
------------------------------
End of WorkS Digest
*******************
Subject: Announcements - ANSI Standards Comm. & NCC82 Call for Papers
∂31-Jul-81 0755 ''The Moderator'' <WorkS-REQUEST at MIT-AI> Announcements - ANSI Standards Comm. & NCC82 Call for Papers
Date: 31 July 1981 06:00-EDT
From: "The Moderator" <WorkS-REQUEST at MIT-AI>
To: WorkS at MIT-AI
WorkS Announcements
----------------------------------------------------------------------
Date: 29 July 1981 01:31-EDT
From: Steven T. Kirsch <SK at MIT-MC>
Subject: X3V1 comm. for ANSI Standards in the area of Office Systems
There are four working groups:
1. User interface requirements
2. Terms and functions for office systems
3. Distribution of information (e.g., message interchange format)
4. Text communications (e.g., page image format)
They welcome new members. West coast people are especially invited
to participate. Meetings are held in Washington, DC.
For further information, contact:
L. M. Collins, Chairman
X3V1 IBM Corp
2300 One Main Place
19th Floor
Dallas, TX 75250
------------------------------
Date: 28 July 1981 17:59 edt
From: Frankston at MIT-Multics (Bob Frankston)
Subject: NCC 1982 Personal Computer Sessions -- Call for papers etc.
The 1982 National Computer Conference will have a track (i.e.,
a group of sessions) on personal computers. This means that
the papers will be refereed and appear in the proceedings.
This is in contrast to past years in which there was a
separate, unrefereed "subconference".
This reflects the growth and importance of personal computers.
But it is also a challenge. We must organize a new set of
sessions and get new referees. Part of this challenge is in
finding a balance between sessions on the mature areas in
personal computing and capturing the innovation in ongoing
research and development, both in academic and commercial
projects. Workshops might provide a better forum for the
latter.
Some of the possible topics include:
- what are personal computers -- the definitions range
from Alan Kay's dynabook, to miniature mainframes to
workstations.
- what personal computers are not.
- specific applications and issues such as wordprocessing
(though word processing also falls under office automation)
- Protocols and standards
- Networking as it relates to personal computers. This
can represent both local area networks as well as ad
hoc telco networks.
- Operating systems -- both traditional and new concepts
- Languages
- Consumer computers -- issues in design, implications of
a software marketplace.
- Education -- traditional and otherwise, computer and
noncomputer
- Implications and relationships to other fields both
within the industry and in the rest of the world.
Societal interactionals.
- Hardware trends and issues
- Games, both recreational and educational.
I am on the NCC steering committee and am in charge of
organizing/creating these sessions. If you have any
suggestions or comments, and if your are interested in
participating by writing a paper, refereeing or whatever,
please contact me either as:
nccpc82.SoftArts at MIT-Multics
or
Bob Frankston
Software Arts, Inc
PO Box 527
Cambridge, MA 02139
or 617-491-2100.
------------------------------
End of Announcements
********************
We would like to report on the SUN workstation at ncc-pc.
Please send me an author's kit at:
Andreas Bechtolsheim
PO BOX 3005
Stanford, CA 94305
We might also help to review some papers.
∂23-Aug-81 0858 AVB
∂22-Aug-81 0646 DUFFEY at MIT-AI (Roger D. Duffey, II) WorkS Digest V1 #9
Date: 22 AUG 1981 0917-EDT
From: DUFFEY at MIT-AI (Roger D. Duffey, II)
Subject: WorkS Digest V1 #9
To: WorkS at MIT-AI
WorkS Digest Sat, 22 Aug 1981 Volume 4 : Issue 9
Today's Topics:
Workstations - IBM's Personal Computer
----------------------------------------------------------------------
Date: 18 Aug 1981 1406-EDT
From: Willie Lim <WLIM at MIT-XX>
Subject: IBM Personal Computer
For more details on the IBM new personal computer see a full page
ad (page 16) in Monday's Wall Street Journal (8/17/81). There is
a number one can call : 1-800-431-2670. But Rubin's mail to
WorkS seems to have quite a good description of the system.
Willie
------------------------------
Date: 18 Aug 1981 1415-EDT
From: Willie Lim <WLIM at MIT-XX>
Subject: IBM new PC
There is a rumour that the S-100 bus is (or going to be) on the new
IBM PC. Is this true?
Willie
------------------------------
Date: 20 Aug 1981 (Thursday) 1737-EDT
From: DREIFU at WHARTON-10 (Henry Dreifus)
Subject: IBM Personal Computer
Would someone collect information on the IBM Personal Computer,
and then send it out to the list? Here is all that I know about
it:
Processor Class: 8086 (lets face it, its a display-writer)
Up to 256 K memory
Either Floppy (avail now) or Winchester drives.
Can run DOS, a version of CP/M or IBM's own OS.
Will have EasyWriter & VisiCalc; not sure on Wordstar.
It is clearly going to be more powerful in the long run over
8080 class microprocessors.
For more info, they have an 800/431-2670 number for information
pacquets.
Hank
------------------------------
End of WorkS Digest
*******************
∨
∂31-Aug-81 1053 MJN
∂31-Aug-81 0013 DUFFEY at MIT-ML (Roger D. Duffey, II) WorkS Digest V1 #10
Date: 31 AUG 1981 0142-EDT
From: DUFFEY at MIT-ML (Roger D. Duffey, II)
Subject: WorkS Digest V1 #10
To: WorkS at MIT-AI
WorkS Digest Mon, 31 Aug 1981 Volume 1 : Issue 10
Today's Topics:
Workstations - IBM's Personal Computer, Working While Flying
----------------------------------------------------------------------
Date: 23 Aug 1981 1700-EDT
From: GILBERT at MIT-XX (Ed Gilbert)
Subject: IBM's personal computer: S100?
I saw a sales presentation and a couple of prototypes the other
day. From what I remember, the cards did not look like S100
cards. During the presentation, they promised to publish the
bus specs, so we can assume that it isn't S100. However, they
seem to be encouraging a plug-compatible market, so it should
soon grow to be as large as the S100 market.
Someone sent a message to this list some time ago describing
the system. I learned little of significance at the presentation
that was not in that message. I do want to clarify something
that could cause confusion. The DOS that is offered with the
personal computer is not the same one that runs on the main-
frames. If you think about it that would be very difficult
to do, but IBM hasn't been very clear about it. I am told
the new DOS is of the same flavor as CP/M.
------------------------------
Date: 26 August 1981 1153-EDT (Wednesday)
From: Marc.Donner at CMU-10A
Subject: IBM Personal Computer
I saw some of the discussion of the IBM personal computer
in the Apollo bboard at CMU. I just left IBM Yorktown
Heights and I brought with me a copy of the 'blue letter'
that announced the PC. I will be glad to send you any
information from it that you want ... it is public
information. I don't have it with me physically right
now, but here is some of the gist:
In the beginning IBM will be selling two basic configurations:
Configuration 1 includes 'System Unit', Keyboard, 48K RAM,
40K ROM, floppy disk controller and one floppy (5-1/4 inch
minifloppies). Configuration 2 is same as configuration 1
with addition of another 16K RAM (total 64K) and the other
floppy. The system unit has capacity for up to five cards.
One option that you MUST buy before you may use the system
is one of three video interfaces. One interface connects
to the IBM monochrome display, one connects to a TV modulator,
and one connects both to the monochrome display AND to the
printer. The list price for Configuration 1 is about 2300
dollars. For configuration 2 the list is about 3000 dollars.
Oh, one thing that is also included in the Configuration 1
and 2 systems is the Asynchronous Communications Interface.
All software beyond the ROM Basic (by MICROSOFT) is extra
cost. Asynchronous communications software is $40, Pascal
is $300 (requires two floppies and big memory, I think),
Adventure is $30 ... more details when I have the blue
letter in my hand. The minimal systems (system unit, 16K
RAM) will only be available from Sears and Computerland.
Volume discounts are available ... 5% for more than 20
units on up to 15 or 20% for >100 units.
The processor is an Intel 8088, which is the 8 bit bus version
of the 8086 ... it is a 16 bit machine shouting through a small
hole. The processor cycles at almost 5MHz. Assuming three
byte instruction and one data fetch or store per instruction,
there will be five memory transactions per instruction ... if
memory cycles at system clock speed (I think that this is so)
then they get about 1 microsecond per 8086 instruction. The
first 64K of RAM plug into sockets on the main processor board
... you don't have to buy the RAMs from IBM ... you can get
the chips from a distributor and save bucks.
Almost all of the software (read ALL) is from outside. The
floppies and the printer are also OEM components that IBM
buys. The monochrome display is capable of displaying 25
lines of 80 characters ... the TV interface is limited to
25 lines of 40. The monochrome display may have monochrome
graphics ... the announcement is quite vague.
I priced out the nicest combination of goodies that would
go together in the box ... two floppies, 192K RAM, printer,
display, communications, and it came to about $6K sans
software.
Please let me know if you want more details.
Marc
------------------------------
Date: 27 Aug 1981 1743-PDT
From: Zellich at OFFICE-3 (Rich Zellich)
Subject: Working while flying - airborne phones coming
From the 26 Aug 81 issue of MIS Week newspaper:
W.U. TO ACQUIRE 50% OF AIRFONE
Upper Saddle River, N.J.
- Western Union Corp. said last week it has agreed to acquire
a 50 percent interest in a new communications system, owned by
Airfone Inc., that will allow passengers on commercial airlines
to place a telephone call while in flight.
According to Western Union, Airfone has received a developmental
license from the Federal Communications Commission (FCC) to
provide a nationwide, fully automatic air-to-ground radio
telephone communications service.
Initially, Western Union said, service will be provided through
air-to-ground telephones installed in wide-bodied aircraft, which
in turn will be linked with multiple ground stations providing
coast-to-coast coverage. It said a passenger would be able to
place a call by using portable telephones located in various
sections of the aircraft.
The system, it said, is expected to be operational during the
second half of next year.
------------------------------
Wonder if I'll be able to use my TI745 with this service...or
better yet, the still-to-come portable CRT connected to my
still-to-come stand-alone home workstation? -Rich Zellich
------------------------------
End of WorkS Digest
*******************